Non-conformance
Recommended approach to Sage X3 Non-conformance management
It is 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.
The Sage X3 Non-conformance management functionality assumes this process is taking place in your organization.
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 raising 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'.
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 raise (or report) incidents of non-conformance, or manage reported incidents of non-conformance raised directly from an associated transaction such as a Purchase receipt. Your quality procedures might indicate 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 raise non-conformance incidents.
Having raised 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 (see Recommended approach to Sage X3 Non-conformance management above) 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 parameter NCSDEL - Delete non-conformance (chapter TC, group NCS) is set to 'Yes' and the non-conformance is at status 'New'. Otherwise it must remain on file for audit purposes.
Prerequisites
Refer to documentation Implementation
Screen management
The Non-conformance function contains a Home section section and one section per feature of the corrective and preventive process:
- Home section. The Home section provides key tracking information. It contains the key field – Status – which indicates the current stage of this non-conformance incident in the corrective and preventive cycle. You can pin this section so that it does not scroll off the page.
- Identification. This is the main section for this function. You use it to articulate the details of the reported, or observed non-conformity. It is 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.
Header
The Home section provides key tracking information. You can pin this section so that it does not scroll off the page.
The critical field in the Home 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 raised directly from a particular transaction such as a Purchase receipt or Customer return many fields in this section will be 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 individuals (internal or external). 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, 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.
Note the following rules if you intend to add (link) 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 are 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 must be logged in as the current QA manager for this incident.
| Site (field SITE) | ||||||||||||||
|
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 (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:
You can change the site code whilst 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 must display status 'Closed'). You can then raise a new non-conformance for the correct site. |
||||||||||||||
| Non-conformance (field NCSID) | ||||||||||||||
|
This field displays the unique identifier for this incidence of non-conformance.
|
||||||||||||||
| Status (field NCSSTA) | ||||||||||||||
|
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.
|
- Description (field TITLE)
Use this field to provide a short description of this incidence of non-conformance (maximum 50 characters).
Leave the default description displayed if this non-conformance was raised directly from an associated transaction (such as a Purchase receipt or Customer return), or type in a short description of this incident. The default description is one of the following:
This field is mandatory.
- Origin (field NCSCATEGOR)
This field displays the category of reporter (or source) that observed, or reported the non-conformity if this non-conformance was raised directly from an associated transaction (such as a Purchase receipt or Customer return). Leave the value displayed or select a different category of reporter. This field is mandatory.
The list of categories is defined in Local menu 3715.
- Supplier (field NCSBPS)
This field is only available for entry if the Origin field is set to 'Supplier', 'Internal' or 'External'. This field determines which documents can be linked to this incidence of non-conformance.
Note the following before deciding whether you should add (or clear) a Supplier code.
Leave the supplier code displayed if this non-conformance was raised directly from a Purchase receipt; Type in, or select from the BP Suppliers table (table BPSUPPLIER) the code of the supplier that can be identified as the original source or reporter of this incident.
Clear the default supplier code displayed if this non-conformance was raised directly from a Purchase receipt to leave this field blank.
Add the suppliers directly into the Reported by section.
Add the 'reporters' directly into the Reported by section.
Add the 'reporters' directly into the Reported by section.
You can only identify a supplier or a customer, not both, as the source of this incident, or you can leave the supplier/customer blank. If you leave it blank you add suppliers and customers directly into the Reported by section instead and the documents you can link to it are not constrained.
- Customer (field NCSBPC)
This field is only available for entry if the Origin field is set to 'Customer', 'Internal' or 'External'. This field determines which documents can be linked to this incidence of non-conformance.
Note the following before deciding whether you should add (or clear) a Customer code.
Leave the customer code displayed if this non-conformance was raised directly from a Customer return; Type in, or select from the BP Customers table (table BPCUSTOMER) the code of the customer that can be identified as the original source or reporter of this incident.
Clear the default customer code displayed if this non-conformance was raised directly from a Customer return to leave this field blank.
Add the suppliers directly into the Reported by section.
Add the 'reporters' directly into the Reported by section.
Add the 'reporters' directly into the Reported by section.
You can only identify a supplier or a customer, not both, as the source of this incident, or you can leave the supplier/customer blank. If you leave it blank you add suppliers and customers directly into the Reported by section instead and the documents you can link to it are not constrained.
- Product (field PRODUCT)
You use this field to identify the product a 'problem' or 'defect', or failure or potential failure in design or production, or process has been observed against.
If this non-conformance was raised directly from an associated transaction (such as a Purchase receipt or Customer return) you can leave the product code displayed or type in, or select the product code that has been reported as defective. Where the associated transaction is a Production tracking operation, the default product code is the first released product on the work order. Should the work order contain multiple products to be released you can change the displayed product code to any product code associated with the work order, including to the routing product code if different to a released product code. The product code in the linked document line is changed to your 'new' product code.
If this non-conformance applies to a system or non-stock item such as documentation, procedure or training leave this field blank.
You can only raise a non-conformance incident for a single product code or process (blank).
You can change the product code as required whilst this non-conformance incident is at status 'New'.
- Major version (field ECCVALMAJ)
Use this field to indicate which major 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.
Type in, or select a version code from the list of version codes displayed. This field is not available for entry if the product code defined in the Product field is not version managed.
- Minor version (field ECCVALMIN)
Use this field to indicate 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.
Type in, or select a version code from the list of version codes displayed. This field is not available for entry if the product code defined in the Product field is not version managed.
- Created date (field CREDAT)
This field displays the date this incidence of non-conformance was raised (entered).
- Created by (field CREUSR)
This field displays the code and name of the user that raised (entered) this incidence of non-conformance.
- Closed status (field CLOSEDST)
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'.
- Closed date (field CLOSEDATE)
This field, if populated, displays the date this reported non-conformity was officially closed.
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 is '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 (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 also use this section to link to and view actual documents the observed problem has been reported against.
If this non-conformance was raised 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 is at status 'In review', 'In planning' or 'Being implemented'. 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 whilst the non-conformance incident is at status 'New'. 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 parameter NCSDOCCHG - Linked document change is set to 'No', the status of a non-conformance is 'Being implemented' and the corrective and preventive Action plan is being implemented (actioned).
Note the following rules 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 must 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 parameter NCSMULTIWO - Link prod tracking multiple WO (chapter TC, group NCS) is set to 'No'.
Image
| Image (field IMG) |
|
Use this field to select an image to display on this record. |
Description
| Probable cause (field NCSPROCAU) |
|
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) field 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. |
| Additional information (field NCSDES) |
|
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 raised 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) |
|
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 raised directly from an associated transaction this field will display the linked transaction type.
|
| Document number (field VCRNUM) |
|
Use this field to identify the number of the source document or order. |
| Line number (field VCRLIN) |
|
Use this field to identify the associated line on the source document or order. |
| Product (field ITMREF) |
|
This field displays the product code from the selected source document or order line. |
| Major version (field ECCVALMAJ) |
|
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. |
| Minor version (field ECCVALMIN) |
|
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. |
| NC quantity (field NCSQTY) |
|
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. |
| Original quantity (field DOCQTY) |
|
This field displays the quantity from the source document or order line. The quantity is expressed in the stock unit. |
| Stock unit (field STU) |
|
This field displays the unit in which the product is stored. It provides the key to prices, costs, volumes etc. |
| Document date (field DOCDAT) |
|
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). |
| Supplier (field BPSNUM) |
|
This field displays the code of the supplier for which the source document or order was raised. It is only displayed if the source Document type (field DOCTYP) is a Purchasing document. |
| Customer (field BPCNUM) |
|
This field displays the code of the customer for which the source document or order was raised. It is only displayed if the source Document type (field DOCTYP) is a Sales document. |
| Project (field PJT) |
|
This field displays 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'.
|
| Line status (field LINSTA) |
|
This field indicates if this particular line is considered active and relevant to this non-conformance incident. Click the Deactivate document/Activate document action to change its status. |
| Customer return | ||||||||||||||
|
Click 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 | ||||||||||||||
|
Click 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 | ||||||||||||||
|
Click 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 | ||||||||||||||
|
Click Deactivate document from the Actions icon to exclude (or cancel) this source document or order line. To reinstate this (cancelled) line, click Activate document. |
||||||||||||||
| Document line | ||||||||||||||
|
Field descriptions
Block number 1
|
||||||||||||||
| NC quantity (field NCSQTY) | ||||||||||||||
|
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 of the product on 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. You can change this figure as required (although it cannot exceed the original quantity). The quantity is expressed in the stock unit.
|
||||||||||||||
| Original quantity (field DOCQTY) | ||||||||||||||
|
This field displays the quantity from the source document or order line. You cannot change this figure. The quantity is expressed in the stock unit. |
||||||||||||||
| License plate number (field LPNNUM) | ||||||||||||||
| Supplier lot (field BPSLOT) | ||||||||||||||
|
The supplier lot number can be entered for information purposes in the receipt transactions, and displayed in the stock issue transactions. It is recorded in the stock file and corresponds to the internal lot number. This ensures that the origin of goods can be tracked. |
||||||||||||||
| Lot (field LOT) | ||||||||||||||
|
This field displays the lot associated with the product on the source document or order line. You cannot edit this field. |
||||||||||||||
| Sublot (field SLO) | ||||||||||||||
|
This field displays the sublot associated with the product on the source document or order line. You cannot edit this field. |
||||||||||||||
| Serial number (field SERNUM) | ||||||||||||||
|
This field displays the serial number of the product on the source document or order line. You cannot edit this field. |
Click 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 click the Select all/Deselect all actions in the Document line screen to select or clear all lines displayed in the table (grid).
| Document number (field DOCNUM) |
|
This field displays the tracking number generated for a work order released for production. |
| Line number (field DOCLIN) |
|
This field displays the applicable line number in the displayed document. |
| Operation (field OPENUM) |
|
This field displays the sequence number of this operation. |
| Document date (field DOCDAT) |
|
This field displays the date the stock transactions associated with this tracking number were posted. |
| Project (field PJT) |
|
This field displays 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'.
|
| Employee ID (field EMPNUM) |
|
This field identifies the operator that performed this operation. |
| Description (field EMPDES) |
|
This field displays the description from the employee profile and cannot be modified. |
| Actual work center (field CPLWST) |
|
This field identifies the production resource used for this operation. |
| Work center type (field WSTTYP) |
|
This field identifies the type of operation that is performed on the selected work center. This might be a machine, labor or a subcontracted operation. Work centers of type Subcontracting are managed externally by subcontract suppliers. |
| NC quantity (field NCSQTY) |
|
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. |
| Quantity (field DOCQTY) |
|
This field displays the quantity from the source document or order line. You cannot change this figure. The quantity is expressed in the stock unit. |
| Time unit (field TIMUOMCOD) |
|
The time unit defines how time for the operations in this routing is expressed. The time unit can be 'hours' or 'minutes'. It applies to the setup time, run time and the rate for all operations in the routing. |
| Planned unit time (field EXTOPETIM) |
|
This field displays the time it takes to perform this operation for the required number of items (as defined in the field Planned quantity). The operating time:
|
| Actual stp. time (field CPLSETTIM) |
|
This field displays the actual time taken to set up this machinery ready for use. The time is expressed in the defined time unit. The time can be zero (0). |
| Actual run time (field CPLOPETIM) |
|
This field displays the actual time taken to perform this operation for the required number of items. The operating time:
|
| Linked materials (field LNKMAT) |
|
This check box is selected if unplanned materials were associated with the work order when the operation was released for scheduling. |
| Tools (field EQUNUM) |
|
This field displays the code of a tool used in this routing operation. Tools have a product category of 'Tool' (field Tools (field TOOFLG)). |
Click 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 raised against a process.
Tab Review
You use this section to support root cause analysis. It contains two 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 raising 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' must 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' (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 are 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 are 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.
Tip: Use the Assigned as QA manager filter to locate your non-conformances quickly and easily.
As approvers have authority to approve or reject this incident it is important that you give due consideration to which subject matter experts you assign.
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 status 'In planning' or to status 'Rejected'.
- You can only assign 'approvers' to this non-conformance whilst it is at status 'In review';
- As the QA manager for this non-conformance you are the only user authorized to assign 'approvers' to it;
- 'Approvers' must 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 are 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 a not a prerequisite to changing the status of this non-conformance.
Approvers
As an 'approver' you have 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 (project manager) responsible for planning the corrective and preventive actions. The QA manager cannot set your approval status or add comments on your behalf.
Tip: Use the My non-conformances to approve filter to locate your non-conformances quickly and easily.
- You must meet the following conditions to be able to update your assigned transaction type:
- You must be logged into Sage X3 with your user name;
- You must have approval for involvement in your company's Non-conformance management process as an approver, that is, your user parameter NCSAPPROVE - Approver (chapter TC, group NCS) 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' whilst this non-conformance is at status 'In review';
- Your post-review decisions are not a prerequisite to the status of this non-conformance being changed;
Cause
| Root cause (field NCSROOCAU) |
|
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 raised against a resource (work center) used for a work order operation is displayed if defined in the NCSROORES - Default resource root cause (TC chapter, NCS group) parameter; if this incident was raised against an operational process for a work order the default root cause is defined in the NCSROOPRO - Default process root cause (TC chapter, NCS group) parameter. You can change the default root cause, if required.
The list of factors that can cause a non-conformance that should be eliminated through process improvement are defined in Miscellaneous table - Root cause. |
| Reason (field NCSREASON) |
|
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.
The list of reasons for raising a non-conformance is defined in Miscellaneous table - Reasons for Non-conformance. |
| Severity (field SEVERITY) |
|
Use this field to indicate the urgency of corrective or preventive action on this non-conformance. This field is mandatory.
Critical Major Moderate Minor (cosmetic)
|
| Change impact (field IMPACT) |
|
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.
Major Minor Unknown
The list of risk assessments of the impact in correcting or preventing reoccurrence is defined in Local menu . |
| Required date (field DATEREQ) |
|
Use this field to provide a target completion date for delivery of the 'corrected' product or system. |
| Reassigned by (field CHGMANUSR) |
|
This field, if populated, displays the code and name of the last user to change the QA manager field on this non-conformance incident. |
| Reassigned date (field CHGMANDAT) |
|
This field, if populated, displays the last date this non-conformance incident was reassigned to a different QA manager. |
| Planner (field NCSPLANNER) |
|
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 parameter NCSPLADEF - Default planner (chapter TC, group NCS). 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'.
|
| QA manager (field NCSMANAGER) |
|
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 parameter NCSQADEF - Default QA manager (chapter TC, group NCS). 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.
|
Cause description
| Cause description (field NCSCAUDES) |
|
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.
|
Grid Approvers
| Approver (field NCSAPPUSR) |
|
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.
|
| Name (field USERNAM) |
|
This field displays the name of the selected Enterprise Management user. |
| Transaction type (field TRANSTYPE) |
|
Use this field to identify a specific type of business transaction that must 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. |
| Approval status (field APPRSTAT) |
|
Use this field to indicate the current status of the decision in the review of the suggested non-conformity for the assigned transaction type.
Approved Rejected
|
| Reason (field APPRREASON) |
|
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. |
Tab Rejection
This section is used by the QA manager for this non-conformance incident. If you are 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 is 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 must be at status 'Rejected' for the fields in this section to be available for entry. As a minimum, you must 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.
Tip: Use the Assigned as QA manager filter to locate your non-conformances quickly and easily.
- You can only set a rejection reason if this non-conformance is at status 'Rejected';
- As the QA manager for this non-conformance you are the only user authorized to reject it;
- Having all approver post-review decisions at status 'Rejected' is a not a prerequisite to the status of this non-conformance being set to 'Rejected'.
You will lose all information in this section if you subsequently revert the status of this non-conformance to status 'In review'.
| Reason for rejection (field REJECTCOD) |
|
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. |
| Rejected date (field REJECTDAT) |
|
This field, if populated, displays the date this reported non-conformity was formally rejected. |
| Rejected by (field REJECTUSR) |
|
This field, if populated, displays the code and name of the user to formally reject this reported non-conformity. |
| Additional information (field REJDESC) |
|
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. |
Tab Close
This section is updated when you close this non-conformance incident. It states who closed this incident and when it was closed.
There is 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) |
|
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'. |
| Closed date (field CLOSEDATE) |
|
This field, if populated, displays the date this reported non-conformity was officially closed. |
| Closed by (field CLOSEDUSR) |
|
This field, if populated, displays the code and name of the user to formally close this reported non-conformity. |
| Close description (field NCSCLODES) |
|
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. |
Tab Reported by
You use this section to provide contact information for a reporter (or source) of this incidence of non-conformance. Any individual (internal or external), 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 are regarded as the source of this reported non-conformance. Their details will be displayed on the first line of the appropriate table (grid) in the respective Supplier/Customer block. Otherwise you are advised to provide the name and contact details for at least one source of the information at some stage in the corrective and preventive cycle. This will ensure 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 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.
Grid Suppliers
| Supplier (field BPSNUM) |
|
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 (table BPSUPPLIER) the code of a supplier that observes and reports this incident. |
| Supplier name (field BPSNAM) |
|
This field displays the corporate or company name for the selected supplier. |
| Contact (field SUPPCONTAC) |
|
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 (table CONTACTCRM) the code of the contact within this supplier's organization.
|
| Contact name (field SUPPCNTNAM) |
|
This field displays the name for the selected contact associated with the selected supplier. |
| Email (field SUPPCNTEMA) |
|
This field displays the email address for the selected contact associated with the selected supplier. |
| Telephone (field SUPPCNTETS) |
|
This field displays the telephone number for the selected contact associated with the selected supplier. |
Grid Customers
| Customer (field BPCNUM) |
|
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 (table BPCUSTOMER) the code of a customer that observes and reports this incident. |
| Customer name (field BPCNAM) |
|
This field displays the corporate or company name for the selected customer. |
| Contact (field CUSTCONTAC) |
|
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 (table CONTACTCRM) the code of the contact within this customer's organization.
|
| Contact name (field CUSTCNTNAM) |
|
This field displays the name for the selected contact associated with the selected customer. |
| Email (field CUSTCNTEMA) |
|
This field displays the email address for the selected contact associated with the selected customer. |
| Telephone (field CUSTCNTETS) |
|
This field displays the telephone number for the selected contact associated with the selected customer. |
Grid Users
| User code (field USER) |
|
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 (table AUTILIS) the code of a user that observes and reports this incident. |
| User name (field USERNAME) |
|
This field displays the name of the selected Enterprise Management user. |
| Email address (field ADDEML) |
|
This field displays the email address defined on the User record. |
| Telephone (field TELEP) |
|
This field displays the telephone number defined on the User record. |
Grid Others
| Contact (field EXTCONTACT) |
|
Use this field to identify the contact (external) that has observed, or reported this incident. Type in, or select from the Contacts (relationship) table (table CONTACTCRM) the code of the contact that observes and reports this incident. |
| Contact name (field EXTCNTNAME) |
|
This field displays the name for the selected contact. |
| Email (field EXTCNTEMA) |
|
This field displays the email address for the selected contact. |
| Telephone (field EXTCNTETS) |
|
This field displays the telephone number for the selected 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
|
Click 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'.
|
|
Click 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.
|
|
Click 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 must 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.
|
|
Click 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'.
|
Barre de menus
|
Click the Action plans action to view or amend (Planners only) the corrective and preventive actions in the Action plan. |
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 two 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 (field NCSBPS) or field in the Home section is only available for entry if the Origin (field NCSCATEGOR) field is set to 'Supplier', 'Internal' or 'External'; the Customer (field NCSBPC) field 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) field.
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 raising this Non-conformance? How significant is this defect likely to be? Please select an appropriate value for this field to ensure the appropriate 'quality' team can be assigned to investigate the root cause, or failure.
The general parameter NCSQADEF must 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 must have a nominated Quality assurance (QA) manager (field QA manager). 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 check box on their Sage X3 user record is selected and their 'QA manager' approval parameter NCSQAMAN - QA manager (chapter TC, group NCS) 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 parameter NCSQADEF - Default QA manager (chapter TC, group NCS) – but only after their user parameter has been 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 must have a nominated Planner (field Planner). 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 check box on their User record is selected and their 'Planner' approval parameter NCSPLANNER - Planner (chapter TC, group NCS) 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 parameter NCSPLADEF - Default planner (chapter TC, group NCS) – but only after their user parameter has been 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 invalid. 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 status 'In planning' to status 'In review'. 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 have attempted to change to a status that is not a preceding, or the next status in the corrective and preventive cycle. Additionally, some statuses (status 'In planning', 'Being implemented', 'Completed') are directly linked with the status of the Action plan. This can lock (prevent changes to) the non-conformance whilst 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 is associated with the selected customer or supplier.
The Reason for rejection field must contain a valueWhy are you rejecting this incidence of non-conformance? Please select the reason in the field Reason for rejection (field REJECTCOD) to ensure the decision made by the Quality team is recorded formally. You are advised to expand upon the selected reason in the field 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. That is, 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-conformance to which they have been assigned are closedAn 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 two sets of information (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 parameter NCSDEL - Delete non-conformance (chapter TC, group NCS) is set to 'Yes' and the non-conformance is at status 'New'.
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 (field NCSID). 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 once a non-conformance is closed.
You can only deactivate this user when all Non-conformance to which they have been assigned are closedAn 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.