SAP PPPI Process Message Categories
Detailing Process Message Categories
Note the following Points for Process Message Categories
Before going into understanding the Process Instruction Categories in detail, we need to know more about Process Message categories, their configuration, their types and uses.
One should always remember that only process instruction categories are sent to the control recipe destination.
Process message categories and the values for the process message characteristics are sent by the shop floor back to SAP to process the data in SAP.
Process Instruction categories are the carriers of Process messages categories and process message characteristics to the control recipe destination.
Process Message categories are included in process instructions are sent to the internal or external shop floor destinations; once the process message categories reach the destination, the control recipe destinations are supposed to fill up data field values (as process message characteristics values) as requested by SAP to process records in SAP. For example, if the shop floor receives a process instruction category (APROD_1) which is requests process order goods receipt information – (process message category PI_PROD embedded inside the process instruction category). See the figure below to understand how a process message category and process message characteristics is embedded in the process instruction categories.
Configuration of Process Message Categories
A Process message category (for example PI_PROD) can be configured using the transaction code O13C. The following needs to be configured for a process message category:
Step 1:
First you have to define the characteristics in a process message category. A set of process message characteristics which are required for processing the message in SAP are defined in this step. The control recipe destination is supposed to give back the values of the following process message characteristics so as to enable processing of the data in SAP. Some of the process message characteristics (as seen below) are marked with “Required” indicator, which specifies that the value of the required characteristics should mandatory be filled in by the destination (since missing these values would not successful post the goods receipt process message in SAP).
Step 2:
The next step is to define the process message destination address of the process message category (in the same transaction code) – the destination address can a BAPI/functional module or a SAP ABAP table or external function used for processing the desired data by using this process message in SAP.
The first column as seen in the screen shot below shows the heading “Destination”, I would call this field as the “purpose of the destination” for example, you can enter PI03 if you want the destination to process goods receipt and PI05 if you want the destination to process the Phase confirmations and PI14 if you want to create and update batch characteristics etc.
The third column is used to define the “type of destination” whether you are using a “BAPI/FM” to process important transaction codes for goods receipts, goods issues, process order confirmations, batch creation & updation, quality inspection results update etc or you are using a “User defined ABAP Z-table” for posting values to a Z-table in SAP or whether you are using an “external function” to communicate data through process messages or you are using “SAP alert management” or “SAP office user recipient for processing the process message delivering alerts and status of production runs as SMS or emails. In this example, we are using destination type “01” – BAPI, to process the goods receipt process message data in SAP.
The last column called the “Destination address”, this address corresponds to the actual SAP program name of the destination type, used to post the process messages in SAP. In this example as shown in the screen shot below, we are using a destination type “01” and the corresponding BAPI program to process the goods receipts in SAP is “COCI_CONFIRM_MATERIAL_PROD”.
Figure 12
Figure 13
Step 3:
Thirdly you should define the mapping of the process message characteristics values with the target fields of the destination – it can be mapping of process message characteristics with the fields of the BAPI (BAPI is just an example of the destination, you can have other destination types as well which will help post the data in SAP). Right hand are the target fields of the destination (in our example the destination is a BAPI) and on the left hand side we have the process message characteristics defined for the process message category.
Note – You can define “multiple destinations addresses” for a given Process message category and therefore it would not be wrong in saying that you can use a given characteristics (values) of a process message category to post different type of data records in SAP.
For example, the “date of goods receipts” can be used to post the goods receipt BAPI (Destination PI03 - COCI_CONFIRM_MATERIAL_PROD) and at the same time you can use this date to update a batch characteristics value during batch creation (Destination P14 - COCI_CREATE_AND_CLASSIFY_BATCH). Therefore you would map the process message characteristics - “PPPI_EVENT_DATE (date of production) with the target fields of the goods receipt BAPI and also with the target fields of the Batch characteristics value update BAPI.
One can argue with my example, that SAP automatically updates the date of production in the batch characteristics for the characteristics “LOBM_HSDAT” – date of production [as equal to the goods receipt date of the batch] but if the actual date of production is a day before the SAP process order goods receipt, then one cannot use the standard SAP characteristics as the production date. In this case you can manually update a different characteristics as created by you (let’s say – Z_HSDAT, which carries no reference or automatic update facilities)
Creating your own Process Message Destinations:
If you want to create your own Process Message destination, then configure them using transaction code O03C. When creating a process message destination, you should define whether the Z-destination needs to be processed individually or can be processed as a bundle, this can be done using a field called – “Individual”, where you can specify whether each process message should be processed individually one after the other. This indicator should be set for the more complex messages which go to function-module destinations.
You should also create the target fields for the destination so that they can be mapped during process message category creation using transaction code O13C.
Figure 15
Additional notes on types of Process Message Destinations
The Process message category destination types as you see in the above small figure are:
BAPI or Function modules are used to update the process messages in SAP. The process messages once received in SAP are processed using these function modules. You can define your own function modules or you can use the existing standard function modules. Transaction code SE37 can be used to access these function modules.
External Functions to coordinate with the external process control system with process messages through RFC connections (a RFC destination should be created for every external system). Transaction code SM59 can be used to define the RFC destinations to communicate with the external system.
SAP Office User is a destination type which is used to inform specific SAP users about the status of the control recipe and process messages (in short the status of the production run)
The process message characteristics data can be updated in user Defined ABAP tables. One can define the ABAP tables and access them through transaction code SE11.
Alerts of critical situation or milestones in the production run, from the external control system or internal shop floor operator using the PI Sheets can be sent to the multiple recipients as SMS or email. You can define Alert categories using SAP transaction code ALRTCATDEF.
All the site contents are Copyright © www.sapsword.com and the content authors. All rights reserved.
All product names are trademarks of their respective companies. The site www.sapsword.com is in no way affiliated with SAP AG. Every effort is made to ensure the content integrity.
Information used on this site is at your own risk.
The content on this site may not be reproduced or redistributed without the express written permission of www.sapsword.com or the content authors.