Non-conformance

The Non-conformance function is the central function for managing incidents of non-conformance. It controls every stage of the "corrective and preventive" process within the context of a "problem" or "defect", such as a failure or potential failure in a design or production model, or in a service, or in a process, or in the system. From the initial creating of a non-conformance incident through to the conclusion or successful resolution of a "problem", it manages business risk at every stage in making your product or process "fit for purpose".

Recommended approach to Sage X3 Non-conformance management

It’s generally regarded as good practice to schedule regular meetings to review quality systems, procedures, and regulations. Whether for changes to trends in sources of product and quality information or data information systems, these should include a formal review of results, risk analysis discussions, and to sign off procedures.

The Sage X3 Non-conformance management functionality assumes that this process is taking place in your organization.


Quality control is a critical aspect of the development of a product and for the ongoing maintenance of a product. You can use this function to create or report incidents of non-conformance, or manage reported incidents of non-conformance created directly from an associated transaction such as a purchase receipt. Your quality procedures might indicate that a design or production model does not comply with specifications or a defect in a purchased component is observed. You use the Non-conformance function to gather the critical information, including "in-flight", cold call information into one central repository. The non-conformance incident forms the details of the non-conformity or problem. It becomes the source of the information to support investigations into the root cause, or failure.

All registered Sage X3 users can create non-conformance incidents.

Having created the initial incident, the Non-conformance function then uses standardized procedures to enable efficient handling of subsequent corrective and preventive procedures:

  • Key personnel can be assigned to the incident that can challenge and determine if a problem has been identified. They can record findings from their root cause analysis. These personnel will also be able to provide input for any corrective actions.
  • It provides visibility of all proposed corrective and preventive actions.
    Personnel authorized for involvement in your "corrective and preventive" process can ensure the technical impact of the corrective and preventive actions are quality tested and approved. With easy access to data and the critical information needed to support the corrective and preventive actions, business risk is managed and minimized.
  • The corrective and preventive actions can be adapted where necessary to respond to changing business requirements or further root cause analysis. Unauthorized or unintended deviations can be prevented.
  • The approach to be taken to deliver the corrective or preventive actions, and therefore to eliminate the cause of the problem can be outlined.

You use the Non-conformance function, therefore, to manage your end to end "corrective and preventive" processes in full. When combined with regular review meetings, it provides a highly effective and efficient control mechanism in making your products or processes "fit for purpose".

A non-conformance incident can only be deleted if the NCSDEL–Delete non-conformance parameter (TC chapter, NCS group) is set to Yes and the non-conformance is at New status. Otherwise it needs to remain on file for audit purposes.

Prerequisites

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 Status field which indicates the current stage of this non-conformance incident in the corrective and preventive cycle.
  • Identification. This is the main section for this function. You use it to articulate the details of the reported, or observed non-conformity. It’s critical to the root cause analysis.
  • Review. Use this section to support root cause analysis. The information you add to this block is critical to the success of this incident. It will be used when defining the corrective and preventive actions required to eliminate the root cause or failure.
  • Rejection. This section is used by the QA manager for this non-conformance incident when this incident is formally rejected. Access to the fields is controlled by the Status field in the home section.
  • Close. This section provides closure information for this non-conformance incident.
  • Reported by. Use this section to provide contact information for reporters or sources of this non-conformity.

Home section

The home section provides key tracking information. The critical field in this section is the Status field. This field indicates the current stage of this incidence of non-conformance in the corrective or preventive cycle.

If this non-conformance was created directly from a particular transaction such as a purchase receipt or customer return, many fields in this section are populated from that transaction document. You can leave the default values or change them.

You can identify a specific supplier or customer as the source of this incident, effectively implying this non-conformance is specific to them. Alternatively, you might decide that this non-conformance could affect multiple suppliers, customers, or internal or external users. Should this be the case you should leave the supplier / customer in this section blank and instead add multiple "reporters" directly into the Reported by section.

An incidence of non-conformance can apply to a specific product, or a system or non-stock item such as documentation, a procedure, or training. If a product is version managed, you can add an additional level of detail by specifying which major and minor version this incident is for.

This section displays the name of the person who created this incidence of non-conformance and when they created it.

The following rules apply if you intend to add a document from an associated transaction to support this incidence of non-conformance:

  • If the Product field contains a product code, you can only link a document for that product.
  • If the Supplier or Customer field contains a supplier / customer code, they’re the original source or reporter of this incident. You can only link a document associated with the defined supplier or customer. For example, if a particular supplier is specified in the Supplier field, you can only link a document such as a purchase receipt for that supplier.

There can be multiple non-conformance incidents per product code.

Quality assurance (QA) managers

As the QA manager for this incidence of non-conformance you ultimately have full control over this incident and the progress of it through the corrective or preventive cycle. To advance or reverse the status of this non-conformance, you need to be logged in as the current QA manager for this incident.

Site (field SITE)

The sites or locations where this incidence of non-conformance occurred. Leave the default site displayed or select the required site code.

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

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

See also Reported by section

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

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

The unique identifier for this incidence of non-conformance.

See also Implementation > Sequence numbers
Status (field NCSSTA)

The current stage of this non-conformance incident in the corrective or preventive cycle. It’s updated when the QA manager assigned to this non-conformance incident selects the actions available to them to progress this incident.


The following stages are associated with processing 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.

Non-conformances at New status 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 the In planning status.
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.

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

When a non-conformance has been reviewed, a planner or project manager has been assigned to it and it’s ready for planning, or is currently in planning.

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

A non-conformance can be reverted from In planning to In review status. If the status is reverted, the corrective and preventive action plan is deleted automatically.

In planning status 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 or actioned.

A non-conformance cannot be rejected or reverted to a preceding stage in the corrective and preventive cycle after the planner sets the status of the action plan to Being implemented.

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

When all individual tasks in the action plan have been accomplished. The actioner has set each line to Completed and the planner has changed the status of the action plan to Completed.

Completed status 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 Completed or Rejected status.


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

  • You need to be logged in as the current QA manager for a non-conformance to change its status.
  • A non-conformance cannot be reset to New status.
  • You cannot change any key elements of a non-conformance when the corrective and preventive action plan is being implemented or 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 after 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)

The short description of this incidence of non-conformance.

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 enter 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.
Origin (field NCSCATEGOR)

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.

The list of categories is defined in the 3715 local menu.
Supplier (field NCSBPS)

This field is only available for entry if the Origin field is set to Supplier, Internal, or External. It 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.

  • 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.
    • Select the supplier code that can be identified as the original source or reporter of this incident.
  • If this incidence of non-conformance is applicable to more than 1 supplier, you need to leave this field blank. This will enable you to link documents from multiple suppliers later.
    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 internal or external users, 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 New status or into the Reported by section if it has started the corrective or preventive cycle.

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.

You can only link a document to this non-conformance that's 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. It 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.

  • 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.
    • Select the customer code that can be identified as the original source or reporter of this incident.
  • If this incidence of non-conformance is applicable to more than 1 customer, you need to leave this field blank. This will enable you to link documents from multiple customers later.
    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 internal or external users, 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 New status or into the Reported by section if it has started the corrective or preventive cycle.

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.

You can only link a document to this non-conformance that's associated with this customer if this field contains a customer code.
Product (field PRODUCT)

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 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. If the work order contains 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, a procedure, or training, leave this field blank.

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

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

You can only link a document to this non-conformance that's associated with this product if this field contains a product code.
Major version (field ECCVALMAJ)

The major version of the product that applies. Major versions might be used where there have been increased or significant changes to the original or previous version. The "form, fit, or function" has changed.

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)

The minor version of the product that applies. Minor versions might be used where there have been minor features or changes in functionality, or significant fixes applied to a specific major version.

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)
The date this incidence of non-conformance was created.
Created by (field CREUSR)
The code and name of the user that created this incidence of non-conformance.
Closed status (field CLOSEDST)

If populated, the closed status of this reported non-conformity.

Completed: If this non-conformance is implemented and the product or solution is approved as "fit for purpose" and is complete, and if it’s closed.

Rejected: If this reported non-conformance is rejected and is closed.

If blank, this non-conformance is still "in progress".
Closed date (field CLOSEDATE)
If populated, the date this reported non-conformity was officially closed.

Tab Identification

Reporting a non-conformity for a "problem" or "defect", or failure or potential failure in a design or production model, or in a service, or in a process, or in the system is critical for delivering a product that's "fit for purpose". You use this section to articulate the details of the non-conformity.

  • You can attach an image such as a photograph of the problem.
    You can provide an image for both a product-related incident and a non-product-related incident or process.

    You can use the Attachments icon on the Side bar to attach multiple images. If you do not want to display images, you can remove the Image block using the Customize screen functionality provided with your solution.
  • You can identify the probable or possible cause of the incident.
  • The key element of the reported incident is a statement that describes the "problem" or failure in detail. You should try to quantify the suggested value for the probable cause and list several reasons why. This will help you ensure you have thought about all the possible causes.
    You can provide this statement in a free-format narrative field.
    Your list of reasons will assist the Quality control team in trying to track down the root cause of the incident. If you can explain the potential consequences if the problem or failure is not addressed, and provide a clear request for corrective or preventive action, this will also help. Ultimately, your statement is critical to the Quality control team for analyzing whether the design or production model complies with the set standard and can be considered "fit for purpose".

You can also use this section to link to and view actual documents the observed problem has been reported against.

If this non-conformance was created directly from an associated transaction such as a purchase receipt, its details are displayed in the Source documents block. A QA manager can manually add documents to this block to link the document with any in-progress non-conformance incident that's at In review, In planning, or Being implemented status. Once linked, quantities can be changed, and documents activated and deactivated.

Where a linked document is from a production tracking operation, the default product code is the first released product on a work order. The product code can therefore be changed to any product code associated with the work order while the non-conformance incident is at New status. This might be to a different released product code on the work order or to the routing product code if different to the released product code. The product code in the linked document line is also changed to the new non-conformance product code.

Linking documents, activating or deactivating documents, or amending the quantity from the source document or order line is blocked if the NCSDOCCHG–Linked document change parameter is set to No, the status of a non-conformance is Being implemented and the corrective and preventive action plan is being implemented or actioned.

The following rules apply if adding a document to the Source documents block:

  • You can only select a transaction for the defined product if the Product field in the Home section contains a product code.
  • You can only select a transaction associated with the supplier or customer identified as the original source or reporter of this incident if the Supplier or Customer field in the home section contains a supplier / customer code.
  • Production tracking documents need to be for a single work order if the first linked document on the first document line is a production tracking document and the NCSMULTIWO–Link prod tracking multiple WO parameter (TC chapter, NCS group) is set to No.

Image

Image (field IMG)
Select an image to display on this record.

Description

Probable cause (field NCSPROCAU)

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

The default code and the list of probable causes is defined in the 804–Probable cause miscellaneous table.
Additional information (field NCSDES)

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

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

Grid Source documents

Document type (field DOCTYP)

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

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

Production tracking documents need to be for a single work order if the first linked document on the first document line is a production tracking document and the NCSMULTIWO–Link prod tracking multiple WO parameter (TC chapter, NCS group) is set to No.
Document number (field VCRNUM)
The number of the source document or order.
Line number (field VCRLIN)
The associated line on the source document or order.
Product (field ITMREF)
The product code from the selected source document or order line.
Major version (field ECCVALMAJ)

The major version of the product that applies. Major versions might be used where there have been increased or significant changes to the original or previous version. The "form, fit, or function" has changed.

This field is not populated if the product code defined in the Product field is not version managed.
Minor version (field ECCVALMIN)

The minor version of the product that applies. Minor versions might be used where there have been minor features or changes in functionality, or significant fixes applied to a specific major version.

This field is not populated if the product code defined in the Product field is not version managed.
NC quantity (field NCSQTY)

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

Select the Document line action to change this figure.
Original quantity (field DOCQTY)
The quantity from the source document or order line. The quantity is expressed in the stock unit.
Stock unit (field STU)
The unit in which the product is stored. It provides the key to prices, costs, volumes etc.
Document date (field DOCDAT)
The key date from the home section of the original document or order. For example, this can be the actual receipt date for a purchase receipt, the return date for a customer return, or the follow-up date for a production or operation tracking.
Supplier (field BPSNUM)
The code of the supplier the source document or order was created for. It’s only displayed if the source Document type field (DOCTYP) is a purchasing document.
Customer (field BPCNUM)
The code of the customer the source document or order was created for. It’s only displayed if the source Document type field (DOCTYP) is a sales document.
Project (field PJT)

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

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

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

To provide a quick and easy visual reference, the link to the project or project structure is distinguishable by the number of separator characters used. If there's no separator, the link is made to the project. A single separator character such as an exclamation mark after the project code (the first code) indicates that the link type is a task (the link is to the project operational structure). 2 separators placed after the project code mean that the link corresponds to a budget code (link to the project budget structure).
Line status (field LINSTA)
Indicates if this particular line is considered active and relevant to this non-conformance incident. Select the Deactivate document / Activate document action to change its status.
Customer return

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

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

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

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

Block number 1

Document number (field DOCNUM)
The number of the source document or order.
Line number (field DOCLIN)
The associated line on the source document or order.
NC quantity (field DOCNCSQTY)
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)
The quantity from the source document or order line. The quantity is expressed in the stock unit.
Stock unit (field DOCSTU)
The unit in which the product is stored. It provides the key to prices, costs, volumes etc.

Grid

Line (field SUBLIN)

A line number in this particular table / grid / block.
Select (field SELLIN)

To select this line, select this checkbox. Clear this checkbox to deselect this line.
NC quantity (field NCSQTY)

The actual quantity from the source document or order line that relate to this incident. It will either reflect the original, full quantity 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. It cannot exceed the original quantity. The quantity is expressed in the stock unit.

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)
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)
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’s 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)
The lot associated with the product on the source document or order line. You cannot edit this field.
Sublot (field SLO)
The sublot associated with the product on the source document or order line. You cannot edit this field.
Serial number (field SERNUM)
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 need to match the original quantity. It cannot exceed the original quantity. You also use this action to deselect or select individual product lines associated with a specific lot, sublot, or serial number that are not relevant to this non-conformance.

You can select the Select all / Deselect all actions in the Document line screen to select or clear all lines displayed in the table.
Operation detail
Document number (field DOCNUM)
The tracking number generated for a work order released for production.
Line number (field DOCLIN)
The applicable line number in the displayed document.
Operation (field OPENUM)
The sequence number of this operation.
Document date (field DOCDAT)
The date the stock transactions associated with this tracking number were posted.
Project (field PJT)

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

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

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

To provide a quick and easy visual reference, the link to the project or project structure is distinguishable by the number of separator characters used. If there's no separator, the link is made to the project. A single separator character such as an exclamation mark after the project code (the first code) indicates that the link type is a task (the link is to the project operational structure). 2 separators placed after the project code mean that the link corresponds to a budget code (link to the project budget structure).
Employee ID (field EMPNUM)
The operator that performed this operation.
Description (field EMPDES)
The description from the employee profile. It cannot be modified.
Actual work center (field CPLWST)
The production resource used for this operation.
Work center type (field WSTTYP)
The type of operation that's 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)
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)
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)

The time it takes to perform this operation for the required number of items, as defined in the Planned quantity field.

The operating time:

  • Is defined in hours or minutes (Time unit field)
  • Is expressed for 1, 100, 1,000 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 1,000 units of the finished product, the time necessary to produce this operation is 10 hours to obtain 500 kg.
Actual stp. time (field CPLSETTIM)
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 (CPLOPETIM field)

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, 1,000 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 1,000 units of the finished product, the time necessary to produce this operation is 10 hours to obtain 500 kg.
Linked materials (LNKMAT field)
This checkbox is selected if unplanned materials were associated with the work order when the operation was released for scheduling.
Tools (field EQUNUM)
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 2 blocks:

  • The Cause block is used to identify the single root cause of this incident.

    If as a result of the root cause analysis more than one cause is determined, you could consider creating additional non-conformances to address each root cause. Each root cause will then be corrected or prevented with an individual action plan.
  • Within this block, the likely impact of this defect and the urgency of correcting or preventing it can be defined.
  • As any identified "change" needs to be managed through the critical checkpoints to the conclusion or closure of it, you use this block to assign this incident to the default or an appropriate "QA manager". A QA manager is a subject matter expert with the authority to approve or reject any suggested changes. They might be a member of your organization’s Quality control team, such as a development manager or a test lead. Alternatively, they might be a product manager that assesses products for market suitability.
    You can reassign this incident to a different QA manager if, and when necessary.
  • You can also assign the default, or an appropriate "planner" or project manager to be responsible for managing the "change".
    A different planner can be assigned to this non-conformance if, and when necessary.
  • The Approvers block is used to assign personnel to this incident that can challenge and determine if a problem has been identified.


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

If you’re the QA manager for this non-conformance or a subject matter expert that has been assigned to support investigations into the root cause, or failure, you provide your feedback in this section. If you’re a stakeholder or member of your company's Quality control team or steering committee, you can use this section to view post-review decisions or conclusions.

QA managers

As the QA manager for this non-conformance incident, you use the Approvers block to identify subject matter experts that have the expertise to review and confirm this incidence of non-conformance. They might be, for example, a member of your organization's Quality control team.

You can assign "approvers" to analyze the root cause of this incident and "approvers" that have the skills to confirm quality processes and standards have been followed in making a product or system "fit for purpose". Your approvers should have the skills to approve or reject the suggested incident for an assigned area of expertise.

Use the Assigned as QA manager filter to find your non-conformances quickly and easily.
As approvers have authority to approve or reject this incident, it’s 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 In planning or Rejected status.

  • You can only assign "approvers" to this non-conformance while it is at In review status.
  • As the QA manager for this non-conformance, you’re the only user authorized to assign "approvers" to it.
  • "Approvers" need to be authorized non-conformance management subject matter experts.
  • You can associate multiple "approvers" with this non-conformance.
  • You can associate a single "approver" with multiple transaction types.
  • You do not have authorization to set the approvers post-review decisions.
  • You’re responsible for manually advancing this non-conformance to selected stages in the corrective and preventive cycle.
  • Having a complete set of approver post-review decisions is not a prerequisite to changing the status of this non-conformance.

Approvers

As an "approver" you’ve been assessed as having the expertise to review and confirm an incidence of non-conformance.

You should try to identify the root cause of this incident from the transaction types assigned to you.

Having determined or identified if a problem exists or not, you notify the QA manager for this non-conformance and the stakeholders by setting a post-review decision against each transaction type. One comment field per transaction type is available to you which you could use to quantify your decision. You could use it, for example, to state assumptions or make recommendations to the planner or project manager responsible for planning the corrective and preventive actions. The QA manager cannot set your approval status or add comments on your behalf.

Use the My non-conformances to approve filter to find your non-conformances quickly and easily.

  • You need to meet the following conditions to be able to update your assigned transaction type:

    • You need to be logged into Sage X3 with your user name.
    • You need to have approval for involvement in your company's Non-conformance management process as an approver. Your NCSAPPROVE–Approver user parameter (TC chapter, NCS group) is set to Yes.
  • If site restrictions are in place, visibility of and access to this non-conformance is determined by the value of the Site field.
  • You can only set an "approval status" while this non-conformance is at In review status.
  • Your post-review decisions are not a prerequisite to the status of this non-conformance being changed.
  • The QA manager is not permitted to set your post-review decisions or add comments on your behalf.

Cause

Root cause (field NCSROOCAU)

The single root cause of this incident.

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

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

The list of factors that can cause a non-conformance that should be eliminated through process improvement are defined in the 803–Root cause miscellaneous table.
Reason (field NCSREASON)

The reason why this problem arose in the first place. You should use this field to support the identified root cause following root cause analysis.

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

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

The urgency of corrective or preventive action on this non-conformance.


The following 4 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 or cosmetic: Correcting or preventing the non-conformance is regarded as low-priority, for when time permits.


The list of severity levels is defined in the 2030 local menu.
Change impact (field IMPACT)

An assessment of the impact implementing the "change" resulting from correcting or preventing this non-conformance will have on the current form, fit, and function. Provide your assessment of the risk associated with this, ensuring you’ve considered the effect on existing validated processes.


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

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

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

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

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

The list of risk assessments of the impact in correcting or preventing reoccurrence is defined in the 2031 local menu.
Required date (field DATEREQ)
The target completion date for delivery of the "corrected" product or system.
Reassigned by (field CHGMANUSR)
If populated, the code and name of the last user to change the QA manager field on this non-conformance incident.
Reassigned date (field CHGMANDAT)
If populated, the last date this non-conformance incident was reassigned to a different QA manager.
Planner (field NCSPLANNER)

The planner or project manager that will be responsible for planning the set of "global actions" that will form the corrective and preventive action plan for this incidence of non-conformance. They’ll be responsible for planning the approach to be taken to eliminate the problem. They’ll also be responsible for controlling or managing the corrective or preventive actions, using their action plan, through to a successful correction and approval of a product that's "fit for purpose".

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

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

  • You’re 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. It is not at Closed status.
QA manager (field NCSMANAGER)

The subject matter expert with the authority to categorize, prioritize, approve, or reject, and monitor corrections for the reported incidence of non-conformance. The default quality assurance (QA) manager is the user defined in the NCSQADEF–Default QA manager parameter (TC chapter, NCS group).

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

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

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

  • You’re 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)

A statement of the root cause analysis.

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

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

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

Grid Approvers

Approver (field NCSAPPUSR)

The subject matter expert that has the expertise to review and confirm an incidence of non-conformance.

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

Select a user code from the list of users approved for involvement in your non-conformance management process as subject matter experts.

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

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

The Sage X3 user name.
Transaction type (field TRANSTYPE)

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

The list of transaction types is defined in the 807–Transaction type miscellaneous table.
Approval status (field APPRSTAT)

The current status of the decision in the review of the suggested non-conformity for the assigned transaction type.


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

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

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

  • You need to be logged in as the assigned approver to set an "approval status".
  • You can only set an "approval status" while this non-conformance incident is at In review status.
  • The QA manager is not permitted to set your post-review decision on your behalf.
Reason (field APPRREASON)
Your decision on your review of the suggested non-conformity for the assigned transaction type, in summary. You could use it, for example, to state assumptions or make recommendations to the planner or project manager responsible for planning the corrective and preventive actions.

Tab Rejection

This section is used by the QA manager for this non-conformance incident. If you’re a stakeholder or member of your company's "change board" or steering committee, you can use it to view the formal rejection reason and conclusions.

This non-conformance can only be rejected by the QA manager assigned to it.

QA managers

As the QA manager for this non-conformance, you use this section to formally reject this incident. This is mandatory if the Quality control team conclude there's no problem and the product or solution is "fit for purpose". You might also choose to reject it if it has been created in error or is a duplicate of another non-conformance incident.

This non-conformance needs to be at Rejected status for the fields in this section to be available for entry. As a minimum, you need to define the reason the Quality control team is formally rejecting this non-conformance.

You can expand upon the reason for rejection in a free-format narrative field.

Use the Assigned as QA manager filter to find your non-conformances quickly and easily.
  • You can only set a rejection reason if this non-conformance is at Rejected status.
  • As the QA manager for this non-conformance you’re the only user authorized to reject it.
  • Having all approver post-review decisions at Rejected status is not a prerequisite to the status of this non-conformance being set to Rejected.
You’ll lose all information in this section if you subsequently revert the status of this non-conformance to In review.
Reason for rejection (field REJECTCOD)

The reason the Quality control team is formally rejecting this reported non-conformity, in summary.

The list of rejection reasons is defined in the 808–Reason for rejection miscellaneous table.
Rejected date (field REJECTDAT)
If populated, the date this reported non-conformity was formally rejected.
Rejected by (field REJECTUSR)
If populated, the code and name of the user to formally reject this reported non-conformity.
Additional information (field REJDESC)
Explains the defined reason for rejection. Enter a statement that quantifies the decision to formally reject this reported non-conformity.

Tab Close

This section is updated when you close this non-conformance incident. It identifies who closed this incident and when it was closed.

There's a free-format narrative field which supports the reason for closure if it was completed when this incident was formally closed using the Close action.

Close description

Closed status (field CLOSEDST)

The closed status of this reported non-conformity.

Completed: If this non-conformance is implemented and the product or solution is approved as "fit for purpose" and is complete, and if it’s closed.

Rejected: If this reported non-conformance is rejected and is closed.

If blank, this non-conformance is still "in progress".
Closed date (field CLOSEDATE)
If populated, the date this reported non-conformity was officially closed.
Closed by (field CLOSEDUSR)
If populated, the code and name of the user to formally close this reported non-conformity.
Close description (field NCSCLODES)

Explains or summarizes the "change" that was implemented to correct the problem, or why this incident was rejected and closed.

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

Tab Reported by

You use this section to provide contact information for a reporter or source of this incidence of non-conformance. Any internal or external user, customer, or supplier that has identified a "problem" or "defect", or failure or potential failure in a design or production model, or service, or process, or system can report it and be recorded as a reporter of it.

If you specify a customer or supplier in the home section, they’re regarded as the source of this reported non-conformance. Their details will be displayed on the first line of the appropriate table in the respective Supplier / Customer block. Otherwise you’re advised to provide the name and contact details for at least 1 source of the information at some stage in the corrective and preventive cycle. This will ensure that someone with knowledge of the incident is contactable should investigations or quality tests need clarification at any stage of the processing cycle.

The origin or source of an incidence of non-conformance is essential should further explanation be required or questions need answering. It might be difficult to obtain this information without the name and contact details for at least one source.

Examples of a source of an incidence of non-conformance might be:

  • A product manager that has identified a potential stress test failure in your company’s line of business
  • A customer that has identified a failure in a product when used under specific conditions
  • A network engineer that has identified a lack of capacity in a device
  • A service manager that has identified the failure of your company’s vendor contracts to meet agreed delivery times
  • A Tier 1, 2, or 3 support engineer that has identified a defective part in a network element
  • A security manager responding to a newly discovered vulnerability

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

Grid Suppliers

Supplier (field BPSNUM)

The supplier that observed and reported this incident.

If a supplier code is defined in the home section, their details are displayed in the first line of this table. You can amend this supplier code if necessary.

If this field is blank, you can add details for a supplier that reports this non-conformance incident. Select the supplier code that observes and reports this incident.
Supplier name (field BPSNAM)
The corporate or company name for the selected supplier.
Contact (field SUPPCONTAC)

The contact within this supplier's organization that can be contacted about this observed, or reported non-conformity.

Select the contact code within this supplier's organization.

You can only add a contact that's associated with the selected supplier.
Contact name (field SUPPCNTNAM)
The name of the contact associated with the selected supplier.
Email (field SUPPCNTEMA)
The email address for the contact associated with the selected supplier.
Telephone (field SUPPCNTETS)
The telephone number for the contact associated with the selected supplier.

Grid Customers

Customer (field BPCNUM)

The customer that observed and reported this incident.

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

If this field is blank, you can add details for a customer that reports this non-conformance incident. Select the customer code that observes and reports this incident.
Customer name (field BPCNAM)

The corporate or company name for the selected customer.
Contact (field CUSTCONTAC)

The contact within this customer's organization that can be contacted about this observed, or reported non-conformity.

Select the contact code within this customer's organization.

You can only add a contact that's associated with the selected customer.
Contact name (field CUSTCNTNAM)
The name of the contact associated with the selected customer.
Email (field CUSTCNTEMA)
The email address for the contact associated with the selected customer.
Telephone (field CUSTCNTETS)
The telephone number for the contact associated with the selected customer.

Grid Users

User code (field USER)

The internal user that has observed and reported this "problem" or "defect", or failure or potential failure in a design or production model, or service, or process or system.

Select the user code that observes and reports this incident.
User name (field USERNAME)
The Sage X3 user name.
Email address (field ADDEML)
The email address defined on the User record.
Telephone (field TELEP)
The telephone number defined on the User record.

Grid Others

Contact (field EXTCONTACT)

The external contact that has observed, or reported this incident.

Select the contact code that observes and reports this incident.
Contact name (field EXTCNTNAME)
The name of the contact.
Email (field EXTCNTEMA)
The email address for the contact.
Telephone (field EXTCNTETS)
The telephone number for the contact.

Reports

By default, the following reports are associated with this function:

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

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

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

Select the Plan action if the non-conformance incident has been reviewed and as the QA manager, you’re effectively handing over control of it to the assigned planner or project manager. The status of this non-conformance will advance to In planning and the planner will become responsible for planning approach to be taken to eliminate the problem.

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

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

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

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

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

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

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

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

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

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

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

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

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

Limitations

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 need to follow. These regulations have not been implemented in the Non-conformance functionality because 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 2 locations in which you can report a supplier or customer as a reporter or source of a non-conformance: In the home section and in the Reported by section. The Supplier (NCSBPS field) or field in the home section is only available for entry if the Origin field (NCSCATEGOR) is set to Supplier, Internal, or External and the Customer field (NCSBPC) if the Origin field is set to Customer, Internal, or External. If you do not know the supplier / customer code, leave the field blank. In the Reported by section you use the respective Supplier field (BPSNUM)/Customer field (BPCNUM).

The Reason field must contain a value
or
The Severity field must contain a value
or
The impact field must contain a value

Why are you creating this Non-conformance? How significant is this defect likely to be? Select an appropriate value for this field to ensure that the appropriate "quality" team can be assigned to investigate the root cause or failure.

The general parameter NCSQADEF needs to contain a 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 is 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 is 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 not valid. This might be because they are not an active Sage X3 user or because they have not been authorized for the particular non-conformance management role you tried to assign them to. Although you can associate multiple "approvers" and multiple transaction types with a single non-conformance, you can only associate a single "approver" with a single transaction type.
See also 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 In planning status to In review status. If you confirm your action, the system automatically deletes the corrective and preventive action plan. Are you sure you want to do this?

Non-conformance status is not valid.

A non-conformance is status driven (New > In review > In planning > Being implemented > Completed > Close). You’ve attempted to change to a status that's not a preceding or the next status in the corrective and preventive cycle. Additionally, the statuses In planning, Being implemented, and Completed are directly linked with the status of the action plan. This can lock or prevent changes to the non-conformance while the action plan is in progress.

$1$ is not a contact for $2$

Where $1$ = Contact within selected customer or supplier organization; $2$ = Customer/Supplier. You can only add a contact that's associated with the selected customer or supplier.

The Reason for rejection field must contain a 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’re advised to expand upon the selected reason in the Additional information field (REJDESC).

Duplicate Originator is not allowed.

This incidence of non-conformance has already been reported for the defined product code by this source (supplier, customer, internal user, external contact).

No valid document line.

This message is displayed if an internal link to the attached document line has failed. Check if the defined line on the attached document still exists. It might have been deleted.

Split receipt line selection not allowed.

This message is displayed if the attached transaction line is a purchase receipt line that has been split. The original order quantity has been received in multiple deliveries or it has been distributed to multiple warehouses. You cannot specify a split receipt line. You could link this non-conformance to the transaction header instead of the transaction line.

You can only deactivate this user when all non-conformances to which they have been assigned are closed.

A Sage X3 user can only be deactivated from a specific non-conformance role if all non-conformance incidents to which they have been assigned are closed.

Modifying this document may create discrepancies in the Non-conformances.

Documents can be linked to incidents of non-conformance from a linked function such as purchase receipts when a non-conformity is observed, or added to a non-conformance incident manually. Once linked, non-conformance quantities can be changed and documents activated and deactivated. Changing the source document, however, does not change the non-conformance information potentially leading to discrepancies between the source document and the non-conformance.

Deleting this document does not delete the Non-conformances.

Deleting a document linked to a non-conformance does not delete the non-conformance. A non-conformance incident can only be deleted if the NCSDEL–Delete non-conformance parameter (TC chapter, NCS group) is set to Yes and the non-conformance is at New status.

Non-conformance $1$ does not exist.
or
Unknown error occurred while creating a Non-conformance.
or
Unknown error occurred while updating a Non-conformance.

Where $1$ = Non-conformance ID (NCSID field). This message is displayed if an internal link in the system has failed and it is not able to access the non-conformance incident selected. If a second attempt to access the non-conformance incident fails and the error is redisplayed you should contact your system administrator.

This Non-conformance is now closed. Amendment is forbidden.

No changes are permitted at all after a non-conformance is closed.

You can only deactivate this user when all Non-conformance to which they have been assigned are closed.

A Sage X3 user can only be deactivated from a specific non-conformance role if all non-conformance incidents to which they have been assigned are closed.

Tables used

See also Refer to documentation Implementation