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. 

Warning 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 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 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.

Note:

 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 (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".

Note:

 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 status New. Otherwise it needs to remain on file for audit purposes.

Prerequisites

See also 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 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.

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 created 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:

 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.
Note:

 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)

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

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

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

 Reported by section

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

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

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

Implementation > Sequence numbers
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.


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

New

When a "problem" has been observed 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 and is reported and a new incidence of non-conformance is created.

New is the default status for new non-conformances.

Note:

 Non-conformances at status New can only be deleted if the NCSDEL–Delete non-conformance parameter (TC chapter, NCS group) is set to Yes.
In review

When a QA manager assigns a non-conformance for review.

This stage is regarded as a "Qualification stage". It is not mandatory to set a non-conformance incident to In review as all non-conformances can be advanced directly to status In planning.
Rejected

When a non-conformance is rejected and is to be closed.

A rejection reason needs to be defined when this status is assigned to a non-conformance incident.

Warning A non-conformance can be reverted from status Rejected to status In review if additional information becomes available to support the reported non-conformity. If the status is reverted the system automatically deletes all information previously added to the Rejection section.
In planning

When a non-conformance has been reviewed, a Planner (project manager) has been assigned to it and it is ready for planning, or is currently in planning.

A Planner needs to be assigned to a non-conformance before this status can be selected.

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

Note:

 Status In planning is directly linked with the status of the Action plan.
Being implemented

When the framework of the corrective and preventive Action plan has been outlined and the solution being is ready for, or being implemented (actioned).

Warning A non-conformance cannot be rejected or reverted to a preceding stage in the corrective and preventive cycle once the Planner sets the status of the Action plan to status Being implemented.

Note:

Status Being implemented is directly linked with the status of the Action plan.
Completed

When all individual tasks in the Action plan have been accomplished, that is the actioner has set each line to Completed, and the Planner has changed the status of the Action plan to status Completed.

Note:

Status Completed is directly linked with the status of the Action plan.
Closed

When a "change" to a reported non-conformity is implemented and the product or solution is corrected and approved as "fit for purpose", and is complete and is closed. Or the reported non-conformance is rejected and is closed.

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


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

Note:

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

Corrective or preventive cycle status summary

Non-conformance (NC) status Action plan status Reversal of NC status allowed? Preceding NC status allowed Comments
New
No

In review
No

Rejected
Yes In review Reversal of NC automatically deletes all information in Rejection section.
In planning In planning Yes In review Reversal of NC automatically deletes Action plan.
Being implemented Being implemented No

Completed Completed No

Closed Completed No


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 created 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:

  • The associated transaction type plus transaction number, for example, "Purchase receipt RECFR0110038", "Customer return SRTPT0310002", "Production tracking WOTFR0110011" if this non-conformance was created from the transaction header.
  • The associated transaction type plus transaction number plus line number, for example, "Purchase receipt RECFR0110038 4000", "Customer return SRTPT0310002 1000" if this non-conformance was created from a specific transaction line.

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 created 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.

Warning Note the following before deciding whether you should add (or clear) a supplier code.

  • If this incidence of non-conformance is only applicable to a specific supplier:
    • Leave the supplier code displayed if this non-conformance was created directly from a purchase receipt.
    • Type in, or select from the BP Suppliers table (BPSUPPLIER) the code of the supplier that can be identified as the original source or reporter of this incident.
    Note:

     You can only link a document to this non-conformance that is associated with this supplier if this field contains a supplier code.

  • If this incidence of non-conformance is applicable to more than one supplier you need to leave this field blank. This will enable you to later link documents from multiple suppliers.
    Clear the default supplier code displayed if this non-conformance was created directly from a purchase receipt to leave this field blank. 
    Add the suppliers directly into the Reported by section.
  • If this incidence of non-conformance is applicable to suppliers, customers or other individuals (internal and external)) you need to leave this field blank.
    Add the "reporters" directly into the Reported by section.
  • If you intend to link documents for multiple suppliers or customers to this incidence of non-conformance you need to leave this field blank.
    Add the "reporters" directly into the Reported by section.
  • If you do not know the supplier code leave this field blank. You can add the supplier later, either into this field if this non-conformance is still at status New or if it has started the corrective or preventive cycle, into the Reported by section.
Note:

 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.

Warning You can only link a document to this non-conformance that is associated with this supplier if this field contains a supplier code.
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.

Warning Note the following before deciding whether you should add (or clear) a customer code.

  • If this incidence of non-conformance is only applicable to a specific customer:
    • Leave the customer code displayed if this non-conformance was created directly from a customer return.
    • Type in, or select from the BP Customers table (BPCUSTOMER) the code of the customer that can be identified as the original source or reporter of this incident.
    Note:

     You can only link a document to this non-conformance that is associated with this customer if this field contains a customer code.

  • If this incidence of non-conformance is applicable to more than one customer you need to leave this field blank. This will enable you to later link documents from multiple customers.
    Clear the default customer code displayed if this non-conformance was created directly from a customer return to leave this field blank. 
    Add the suppliers directly into the Reported by section.
  • If this incidence of non-conformance is applicable to customers, suppliers or other individuals (internal and external)) you need to leave this field blank.
    Add the "reporters" directly into the Reported by section.
  • If you intend to link documents for multiple customers or suppliers to this incidence of non-conformance you need to leave this field blank.
    Add the "reporters" directly into the Reported by section.
  • If you do not know the customer code leave this field blank. You can add the customer later, either into this field if this non-conformance is still at status New or if it has started the corrective or preventive cycle, into the Reported by section.
Note:

 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.

Warning You can only link a document to this non-conformance that is associated with this customer if this field contains a customer code.
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 created 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.

Note:

 You can only create a non-conformance incident for a single product code or process (blank).

You can change the product code as required while this non-conformance incident is at status New.

Warning You can only link a document to this non-conformance that is associated with this product if this field contains a product code.
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 created.
Created by (field CREUSR)

This field displays the code and name of the user that created 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).
    Note 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 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 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 while 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.

Note:

 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 (actioned).

Note:

 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 need to be for a single (the same) work order if the first linked document (that is, the first document line) is a production tracking document and the NCSMULTIWO–Link prod tracking multiple WO parameter (TC chapter, NCS group) is set to No.

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) 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 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)

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

Note:

 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.

Note:

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

Note:

 Select the Document line action to change this figure.
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 created. 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 created. 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:

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

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

Note:

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

This field indicates if this particular line is considered active and relevant to this non-conformance incident. Select the Deactivate document/Activate document action to change its status.
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 (cancelled) line, select Activate document.
Document line

Block number 1

Document number (field DOCNUM)

This field identifies the number of the source document or order.
Line number (field DOCLIN)

This field identifies the associated line on the source document or order.
NC quantity (field DOCNCSQTY)

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 DOCDOCQTY)

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

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

Grid

Line (field SUBLIN)

This field displays a line number in this particular table/grid/block.
Select (field SELLIN)

To select this line, select this checkbox; to deselect this line, clear this checkbox.
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.

Note:

 If this particular product line is associated with a specific lot, sublot or serial number the quantity displayed in the Home section will be apportioned over multiple lines.
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)

This field displays the license plate number (LPN) for the product container on the production tracking document line if the product is manufactured and not managed by lot. You cannot edit this field.
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.

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

You can select the Select all/Deselect all actions in the Document line screen to select or clear all lines displayed in the table (grid).
Operation detail
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:

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

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

Note:

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

  • Is defined in hours or minutes (Time unit field).
  • Is expressed for 1, 100, 1000 or a lot of units of the operation based on the management unit,
  • Can be proportional or fixed based on the operating time type.
    For example:
    Time unit = Hours
    Time type = proportional
    Management unit = Time for 100
    Operating time = 2
    Operating unit = kg
    Finished product unit = Un
    REL-OPE conversion coefficient = 0.5
    The operation time is equal to 2 hours for 100 kg. If the Work order is launched for 1000 units of the finished product, the time necessary to produce this operation is 10 hours to obtain 500 kg.
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:

  • Is defined in hours or minutes (Time unit field).
  • Is expressed for 1, 100, 1000 or a lot of units of the operation based on the management unit,
  • Can be proportional or fixed based on the operating time type.
    For example:
    Time unit = Hours
    Time type = proportional
    Management unit = Time for 100
    Operating time = 2
    Operating unit = kg
    Finished product unit = Un
    REL-OPE conversion coefficient = 0.5
    The operation time is equal to 2 hours for 100 kg. If the Work order is launched for 1000 units of the finished product, the time necessary to produce this operation is 10 hours to obtain 500 kg.
Linked materials (field LNKMAT)

This checkbox 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 the product category Tool (Tools field (TOOFLG)).

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

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

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.
    Note 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" 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" (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.

Warning 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.

Note:

 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.

Note:

  • You can only assign "approvers" to this non-conformance while 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" 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 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.

Note:

 

  • 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, that is, 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 status In review.
  • 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)

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

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

Note:

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

The list of factors that can cause a non-conformance that should be eliminated through process improvement are defined in Miscellaneous table 803–Root cause.
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.

Note:

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

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

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


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

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

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

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

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


The list of severity levels is defined in Local menu 2030.
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.


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

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

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

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

Note:

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

The list of risk assessments of the impact in correcting or preventing reoccurrence is defined in Local menu 2031.
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 the NCSPLADEF–Default planner parameter (TC chapter, NCS group). You can assign this non-conformance incident to a different planner, if required. Type in, or select a user code from the list of users approved for involvement in your Non-conformance management process as "planners".

Note:

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

  • You are the current QA manager or Planner for this non-conformance incident.
  • The new planner's User record has approval for the site specified on this non-conformance incident.
  • This non-conformance incident is currently active, that is, it is not at status Closed.
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 the NCSQADEF–Default QA manager parameter (TC chapter, NCS group).

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

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

Note:

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

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

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.

Note:

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

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.

Note:

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

Note:

 This non-conformance incident needs to be at status In review.
Name (field USERNAM)

This field displays the name of the selected Sage X3 user.
Transaction type (field TRANSTYPE)

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

The list of transaction types is defined in Miscellaneous table 807–Transaction type.
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.


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

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

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

Note:

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

Note:

 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 needs to be at status Rejected 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.

Tip: Use the Assigned as QA manager filter to locate your non-conformances quickly and easily.

Note:

  • 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.

Warning 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.

Note:

 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
Note:

 All registered Sage X3 users can add contact details to any new or "in progress" non-conformance incident.

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 (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 (CONTACTCRM) the code of the contact within this supplier's organization.

Note:

 You can only add a contact that is associated with the selected supplier.
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 (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 (CONTACTCRM) the code of the contact within this customer's organization.

Note:

 You can only add a contact that is associated with the selected customer.
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 (AUTILIS) the code of a user that observes and reports this incident.
User name (field USERNAME)

This field displays the name of the selected Sage X3 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 (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 :

Bullet point  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 as you (as the QA manager) can advance a non-conformance directly to status In planning.

Note:

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

Note:

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

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

Note:

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

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

Note:

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

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

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

Note:

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

Note:

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

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

Note:

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

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

Note:

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

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

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

Limitations

Warning Product or safety recalls. You should only use the information in this non-conformance as a guide when a product or safety recall is advisable. Each country has safety regulations and directives for recalls which you must follow. These regulations have not been implemented in the Non-conformance functionality as they can vary from one country to another.

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 (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; 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 value
or
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 needs to contain a value
or
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 has been set.

Please enter Non-conformance Planner
or
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 has been set.

User $1$ is not an Approver for Non-conformance
or
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 proceed if you are the QA manager for this Non-conformance record and the status is In review

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 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 is associated with the selected customer or supplier.

The Reason for rejection field must contain a value

Why 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 are 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. 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-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 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 the NCSDEL–Delete non-conformance parameter (TC chapter, NCS group) 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 (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 once 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

See also Refer to documentation Implementation