Configuring Quality Notifications

Quality notifications can be utilized to effectively manage issues throughout your entire supply chain. Play the video to get familiar with the three standard scenarios in the SAP system.

From a technical perspective, each scenario in SAP corresponds to a specific notification origin. The notification origin is predetermined by SAP and cannot be changed. However, the Application Consultant can define notification types in Customizing to create process variants. Each notification type has its own user interface with different tabs and fields, an action box, and actions, tasks, defects, and causes that are specific to the use case. It is also possible to simplify the data model by excluding certain notification components. For example, the Application Consultant can choose to exclude certain tabs form the UI (for example causes on defect-level) to streamline the process. The following image shows the SAP default settings:

The predefined notification origin in SAP determines the business context of a quality notification. For example, in a customer complaint notification, the sales order or delivery item is displayed as reference objects. On the other hand, in a supplier complaint notification, the purchasing document or material document is displayed. In the SAP-standard, the following notification types are available:

• Origin Customer complaint (Q1):
  • Customer complaint (Q1)
  • Customer-related defect (F1)
• Origin Complaint against supplier (Q2):
  • Complaint against supplier (Q2)
  • Supplier-related defect (F2)
• Origin Internal problem notification (Q3):
  • Internal problem notification (Q3)
  • Material-related defect (F3)

Each origin Qx corresponds to a notification type Qx and Fx. In SAP standard, you manually create a Qx notification if the issue is discovered manually. For example, a customer calls to file a complaint or the warehouse clerk observes an issue with a procured raw material that is already in stock. On the other hand, Fx notifications are used in the context of defect-processing during quality inspections. For instance, when a defect is observed during a goods receipt inspection, you directly create an F2 notification during result recording. In Customizing, the Application Consultant also links the inspection type to the default notification type to define which quality notification is created when the Quality Technician records a defect while capturing inspection results.

If you want to define your own process variants, you can define your own notification types in Customizing.

In this chapter, we will discuss the technical structure and features of a quality notification, independent of their application in a specific business example. The subsequent chapters will cover the application in more detail.

The following image illustrates the data model or technical structure of a quality notification in the SAP system:

A quality notification has the following structural elements:

Using the action box, you can create elements on the notification header or notification item level (for example add actions that document a phone call). You can also perform actions in the SAP system, for example move the affected stock from unrestricted-use to quality inspection, or generate an 8D complaint form for your supplier with data from the notification.

Notification Header

Depending on the customizing settings done by the Application Consultant, each quality notification has one header section (1) and one or more header tabs (2) containing the most important information:

On the header, the system shows the notification number, notification type, status values of the notification and activities, and the notification short text (1). To embed the notification into the logistical context, you can refer to various objects in the SAP S/4HANA system (3). However note that the available reference objects depend on the notification origin:

• Material/plant/batch
• Serial number
• Inspection lot (→ only notifications from defect recording)
• Purchasing document/material document (→ notification origin supplier complaint)
• Production order/production version (→ notification origin internal problem notification)
• Sales order/delivery (→ notification origin customer complaint)

To describe the problem, you can enter the subject in coded form as well as using a short and a longtext (4). To influence the internal processing time line, you can specify the notification priority and various dates (for example start of malfunction, desired start/end date, and so on).

Partner Functions

You use partner functions to describe who is affected by the notification and who performs which activity in the notification. It's possible to differentiate between external and internal partners as shown in the following image:

Partners are all the people, organizational units, and so on, that are directly or indirectly affected by a notification. As shown, it is possible to differentiate between internal and external partners. External partners are, for example:

• Sold-to-party of the sales order
• Contact person at the supplier or customer
• Supplier or manufacturer of the purchased good
• A special address that only applies to this notification

When adding a partner to the notification, the system automatically shows the address from the respective master data record. If you want to use a different address for this specific notification, you can override the address for this specific notification without having to change the master data record.

Internal partners are, fore example:

• Notification author (→ user who created the notification)
• Notification coordinator (→ user who is responsible for the overall notification, for example 8D team lead, CAPA manager, and so on)
• Department responsible

The Application Consultant can also define their own partner functions in Customizing. To specify the underlying master data record of a partner function, such as a user, business partner, or organizational unit, the Application Consultant assigns a partner type to each partner function. They then add a list of partner functions to the notification type. Note that partner functions can be flagged as mandatory and/or unique. Unique partner functions can only be assigned once in the notification, for example, a coordinator. Mandatory partners are automatically added to the notification when it is created, and the user must assign a partner to this function before they can save the notification.

To specify who is responsible for executing a task, a task processor function, such as User responsible, can be assigned to a task on the notification header and/or notification item level.

To find out which partner is assigned to which function in a notification, the selection screens of the worklists for the quality notifications contain an area for an extended partner selection. Here, you can specify partners from different partner functions as selection criteria to select quality notifications and tasks for quality notifications according to specific partners. For example, the 8D coordinator can select all tasks of all notifications where they are assigned as the 8D coordinator to get an overview of the task execution status and to follow up on overdue tasks.

Notification Items

You can add one or more items to the notification to describe, for example, the defective items of a delivery in more detail. A notification item consists of the following elements:

Catalog entry for defect type:	You describe the type of defect, for example, surface defect, functional defect, and so on, in coded form (→ catalog type 9) for evaluation purposes.
Short text and long text:	You describe the type of defect in short text and long text format.
Classification:	You can add additional attributes to the defect, for example, defect is 8D relevant, defect must be reported, and so on. Technically, you create a class (→ class type 15) with one or more characteristics and assign characteristic attributes to the defect.
Catalog entry for defect location:	You describe the location of the defect, for example inside, outside, and so on, on coded form (→ catalog type E).
Assembly/bill of material item:	You enter a material from the BOM that is affected by the defect or causes the defect. For example, a notification was created in the production context with reference to a production order. On the notification header level, the material corresponds to the header material of the production order. However, the order cannot be executed due to one or more defective components that must be assembled. You then create defect items for each defective component and assign the material from the BOM used by the order to trigger repair of the defective component.
Assigned objects:	You can assign several objects at the item level of a notification. This allows better documentation of problems and faults and means less processing effort and fewer notifications. Standard SAP systems contain implementations for the following object categories: Batch Serial Number Inspection Lot Order (production order, process order) Delivery Item (for outbound deliveries) You can implement other object categories by using the BAdI BADI_QNAO_OBJCAT. The Application Consultant can assign the required Object Category for each notification type in QM Customizing under Quality Notifications → Notification Processing → Assigned Objects. You can search for notifications via assigned objects in the worklists and the extended search. In the PDF Forms of the notification shop papers, the assigned objects are displayed as reference information.
Number of defects identified:	The number shows how many identical defects, for example surface scratches, are summarized in the defect item.
Defect valuation:	The number indicates the quantitative weighting of a defect. For example, you can valuate and give a weighting to the defects quantitatively on the basis of damage potential or nonconformity costs.
Non-conforming quantities:	The number shows how many items are non-conforming , for example, the number of defective items in a delivery.

Causes on the Item Level

You can add one or more causes to a defect to document the root cause of a defect. A cause consists of the following elements:

A cause consists of a catalog entry (→ catalog type 5) to describe the root cause in coded form. In addition, the user can provide additional information in short text and long text format.

Actions on the Notification Header and on the Item Level

You can use the activities/actions to document the steps that have already been taken to solve the problem. It consists of the following elements:

Catalog entry:	You describe the type of activity, for example, inform involved parties and so on, in coded form (→ catalog type 8) for evaluation purposes.
Short text and long text:	You describe what was done in short text and long text format.
Processing time frame:	You enter the start and end date/time when the activity was performed.

The elements above apply to actions in the header, as well as actions for individual items in a quality notification. Actions may not be assigned to any partner and have no status. They are used solely for documentation purposes.

Tasks on the Notification Header and on the Item Level

You can use tasks to initiate the activities to be performed. It consists of the following elements:

Catalog entry:	You describe the type of task, for example, trigger root cause analysis, perform rework and so on, in coded form (→ catalog type 2) for evaluation purposes.
Short text and long text:	You describe what must be done in short text and long text format.
Processing deadline:	You enter the planned start and end time as well as the actual completion date of the task.
Processing status:	The execution status of the task, for example task outstanding,task released, task completed, and task successful.
Processing partner:	The partner function, for example the user, who shall perform the task.
Follow-up action:	These follow-up actions are executed automatically as soon as you have processed and saved the notification. For example, adding a task can trigger printing the 8D report.

The elements above apply to tasks in the header, as well as tasks for individual items in a quality notification.

To be able to use follow-up actions, the Application Consultant must have defined them in Customizing. Since they execute function modules, you might also have to involve a Developer if you want to use customer-specific tasks. For more information, refer to the Application Help.

In Customizing, the Application Consultant defines activities for each notification type in the action box. When the user chooses a button in the action box, the relevant activities are executed and documented as an activity or task in the notification header or item. The image below illustrates a notification with three entries in the action box:

In the example, three action box entries are available:

• Log a telephone call: When choosing this action, the system displays a pop-up where the user can record the results of a phone call in a short text and long text field. For example, if the notification is a supplier complaint, the notification coordinator wants to document the details of the return delivery agreed with the supplier in a call or via email.
• Transfer affected quantity to quality inspection: Before returning a potentially defective item to the supplier, the notification coordinator wants to initiate an ad-hoc quality inspection. When choosing this button, the system moves the specified quantity of a material to the quality inspection stock and, if configured in the material master, triggers a stock transfer inspection lot (inspection type 08) to perform the ad-hoc inspection. Depending on the inspection result, the notification coordinator can decide how to proceed further with the defective items.
• Send an email to the supplier: When choosing this button, the system generates and sends an email to the supplier's contact address. The email contains information about the defective items, such as an 8D report template for the supplier to complete.

Depending on the customization settings, the system documents the action as either a task or an activity. For example, when the affected quantity is transferred to quality inspection, the system creates a task that includes the material document number and year for reference. It is also possible to not document an action as a task or activity.

As shown in the following images, SAP offers standard actions. The Application Consultant can also define customer-specific action box entries - we'll explain this in the next section.

The following actions are available in function group QM06:

• Internal note: The system displays a pop-up where the user can enter additional information in a short text and long text field. The system adds this information in an activity.
• Documentation of a telephone call: The system also displays a pop-up where the user can enter information from a phone call. The system adds this information as an activity.
• Create a new quality notification: This action allows you to create a quality notification from a notification. After calling up the follow-up function in the action box, you can first determine the notification type for the quality notification that is to be created. Then you can specify the data for the notification header. The data for the existing notification is proposed.
• Create a repair order: With this module, you can create a repair order from a notification in an RMA (return merchandize authorization) process. After calling up the action box, you can determine the data for the repair order that is to be created.
• Goods movement for repair order: This action is used in an RMA process. It enables you to determine from the notification which quantities are to be repaired, scrapped, and returned to customers. After calling up the follow-up function in the action box, you can save the notification and perform the necessary goods movements in the background.
• Copy decision to repair order: This action enables you to transfer from a notification the usage decision for the returned goods to the corresponding repair order. After calling up the follow-up function in the action box, you can determine the data for the repair order item for which you want to make the usage decision.

The following actions are available in function group QM06:

• Adapt the quality level: These actions allow the Quality Engineer to tighten or reset the quality level for a goods receipt inspection with dynamic modification.
• Send report: These actions create PDF reports with notification data and send them to, for example, the supplier contact person.

The following actions are available in function group QMLR:

• Perform stock postings: The system transfers the notification quantity to blocked stock, quality inspection stock, unrestricted use stock, or scraps the defective quantity. The material document created during this process is stored in the long text of the action.
• Assign supplier or purchasing document: The system proceeds to a search screen where the Quality Engineer can search for the supplier or purchasing document to be assigned to the notification.
• Created/edit a return delivery: This action creates a return delivery in notification processing. If an original purchasing document is assigned to the notification, this return delivery can either be created with or without reference to this original document.
• Create a transport order: This action creates a transport request from notification processing.

How to Define your own Action Box Entries

In this section, we want to explain how the Application Consultant defines an action box entry. The following image illustrates the business scenario (on the right) and the necessary customizing steps (on the left):

The following business scenario for a customer complaint shall be implemented:

1. After creating the notification, the complainant will receive a confirmation receipt.
2. Once the notification is closed and the issue is solved, the complainant will receive a final notice. The final notice can only be sent after the confirmation receipt or an interim report has been sent.
3. Additionally, if desired, an interim report can be sent to the complainant to provide updates on the current processing status of their complaint. The interim report can only be sent after the confirmation receipt has been sent.

The Application Consultant performs the following steps:

1. Define the individual activities as action box entries.
2. The activities "Send receipt of confirmation" and "Send final notice" will be flagged so that the user can only perform them once in a notification.
3. The activity "Send interim notice" is a follow-up of "Send receipt confirmation". The activity "Send final notice" is a follow-up of "Send receipt confirmation" and "Send interim notice".

The following image shows how the Consultant configures the activity "Send Interim Notice":

On the detail screen, the Consultant defines the following:

1. Action text to be displayed in the transaction
2. The action can be executed when creating and changing a notification, but not in display mode. The action is documented as task.
3. The function module 3a is called when the activity is executed. It determines who shall receive the interim report. The function module 3b is called when saving the notification. It generates the PDF document and sends it.
   Hint

   You can use the Function module QM06_FA_ACTION_INTERNAL_NOTE_I to document an internal note as an activity at item level. This function module is ready to run and can directly be included in your action box. The function module QM06_SELECT_ITEM can be included in existing customer-specific function modules. The function module provides a popup in order to select a defect item and transfer the information to the application.

   The function groups QM10 includes the copy templates for own function modules. When you use the action box, please also pay attention to the documentation in Customizing.

4. How the activity is to displayed in the action box (icon, text, or both).
5. Which code group and code is to be entered for the generated task or activity in the notification.
6. The activity depends on other actions and can only be performed after the other action(s) have been performed. The dependencies are set up in the other action(s). This activity can be performed multiple times.

The following screenshot shows the dependency settings in the action "Send Confirmation of Receipt":

A dependent follow-up function only becomes active if it is explicitly allowed by another activity. In the example, triggering the action "Send Confirmation of Receipt" allows the user to perform the actions "Send Interim Notice" and "Send Final Notice".

In regulated industries, for example medical devices, pharmaceutical industry, electronic device manufacturing, food and drugs, and so on, you can use digital signatures in the context of notification processing. The following image shows what's possible:

The SAP S/4HANA system provides digital signatures at both the notification header and task levels when changing a system status. These digital signatures serve as the electronic equivalent of a signature on paper, confirming the user's intention to perform an action. To initiate a status change, the user must enter their username and password. Only when the correct credentials are provided will the system execute the status change. For added security, signature cards can also be used as an alternative to entering a username and password.

The importance of different status changes may vary based on business requirements. Therefore, the Application Consultant defines various signature strategies in the system's customization settings and assigns them to specific business transactions. These strategies determine whether a single person's signature is sufficient or if multiple signatures are required to complete a status change.

Once the signature process is initiated with a synchronous signature strategy, it must be completed without interruption. This may involve gathering all relevant individuals at one computer to perform the necessary signatures. During this process, no new functions or transactions can be accessed until all required signatures have been obtained. If the signature process is interrupted before completion, any previously executed signatures are saved but are not considered valid and must be repeated.

In an asynchronous signature strategy, individuals can perform their signatures at their respective computers and save their progress. Subsequently, another person can continue the signature process by accessing the notification or task on their own computer. If the signer can be changed, the user's name can be modified so that a different individual can perform the signature at the end of the day. This flexibility is particularly relevant in scenarios where multiple users share the same workstation, such as in a laboratory setting.

The Application Consultant defines the digital signature in QM Customizing (Quality Management → Quality Notification → Notification Processing → Digital Signature) on the level of the notification type and the business transaction.

For example: At header level of the quality notification, the following business transactions may require a digital signature:

• PMM2: Put notification in process

• PMM4: Complete notification

• PMM6: Put a notification in process again

For example: At task level of the quality notification, the following business transactions could use a digital signature:

• QN40: Release task

• QN41: Complete task

• QN42: Task successful

In the quality notification, you can obtain an overview of the executed digital signatures by choosing More → Extras → Notification Documents → Digital Signature.

To display the logs for the digital signature, you can use transaction DSAL (in the quality management menu, choose Quality Management → Quality Inspection → Info System → Digital Signature → Logs).

For each step of the digital signature process, the Consultant can specify signature remarks that are displayed to the signatory in the dialog box for the digital signature. The Customizing activity (Quality Management → Quality Notifications → Notification Processing → Digital Signature → Define Signature Remarks) is provided for this purpose. You can also use placeholders to include context information in the signature remark (for example, &6 for Notification number). When performing a signature, the system automatically replaces the placeholders in the remark. For example,

1
Resolution for complaint &6 approved at &9 &10.

translates to

1
Resolution for complaint 1000004305 approved at 01.12.2024 08:00.

when the user performs the signature.

The following image shows a list of system status values and user status values and their potential effect on business transactions:

A system status is predefined in the system by SAP and cannot be changed. The following status values on the notification header level are possible:

• Outstanding: The notification was created during defects recording, but has not yet been activated.
• In process: The Quality Engineer set the notification in process and the issue team analyzes the defect and performs tasks.
• Order assigned: A QM order has been assigned for recording defect costs.
• Postponed: Notification processing has been postponed until further notice.
• Completed: The Quality Engineer closed the notification since the issue has been resolved and all tasks have been completed.
• Defects recording: The notification was created during defects recording.

In addition, the Application Consultant can freely define a user status profile in Customizing. In our example, the user status flags the notification as reporting-relevant and ready for archiving.

A system status can influence the allowed business transactions. For example, a notification with the system status In process cannot be set to "In process" again, as it is already in that state. However, the Application Consultant can also define in the user status profile that if a user status is set, a business transaction that is not forbidden by the system status is still forbidden until the respective user status is removed. For example, setting the user status Archive could prevent a closed notification from being re-opened.

In general, a (system and user) status can have the following effect on a business transaction:

• Allow a business transaction: In this case, the user can perform the business transaction.

• Allow with warning: In this case, when trying to perform the business transaction, the system raises a warning message that the user can confirm.

• Prohibit: In this case, the user cannot perform the business transaction and the system raises an error message.

Furthermore, note that performing a business transaction activates one status, while it might delete another status. For example, setting the notification in process, removes the status Outstanding and sets the status value In Process.

The image below illustrates how an active status enables specific business transactions and how performing a business transaction disables one status and sets another status. For example, when a user chooses to perform a business transaction, the active status allows them to carry out the transaction. However, this action also disables the previous status and sets a new status, indicating that the transaction has been initiated.

Initially, the status OSNO - Notification Outstanding (1) is active since the notification was created during defect recording, but it has not been activated. This status allows for the business transactions Put a notification in process and Complete notification to be executed (2). The user performs the business transaction Set in process (3). Now, the new object status NOPR - Notification in Process (4) is active. The latter allows for the business transaction Complete notification to be executed (5).

The following image shows an example of a user status profile the Application Consultant defined in Customizing:

The Consultant defined a status profile with four status values:

1. INIT - Notification Initialized
2. REL - Released for Processing
3. LBK - Processing Blocked
4. CANC - Notification Canceled

The initial status (1) for notifications is set as "INIT" to automatically apply this status when creating a notification. The status values "REL," "LBK," and "CANC" must be manually set. No authorization object is assigned to any status value (2), so no additional checks are performed. However, you can limit who can set or remove a status by assigning an authorization code. It is important to note that all four status values have a number (3), meaning that only one of the four status values can be set. It is also possible to set multiple status values simultaneously, but they must not have a status number. Additionally (4), "REL" and "LKD" have a lowest status number of 2 and a highest status number of 4. Once either "REL" or "LKB" is set, the user cannot set "INIT" anymore. Similarly (5), since "CANC" has both a lowest and highest status number of 4, once "CANC" is set, a lower status cannot be set anymore. From a business perspective, "CANC" is a final status that cannot be undone.

The Consultant can define which business transactions are allowed or forbidden once a status value is set by double-clicking on it. For example, they could specify that once a notification is canceled (CANC applies), it cannot be set to "in process" again. From a business perspective, it is possible to define that the coordinator reviews the notification once it is created. If they determine that the notification is no longer needed or is a duplicate created accidentally, they can set the CANC status to prevent further processing of the notification.

After having defined a status profile, the Consultant assigns it to a notification type. It's possible to assign one status profile to the notification header level and a different status profile to the task level, if this is required by your business process.