Instrumentation for Procure-to-pay process on item level in Process Observer

ajaleshp_gopi · ‎07-08-2013

Instrumentation for Procure-to-pay process on item level in Process Observer

Hello,

This blog post is part of a series of blog postings about “Process Observer for Built-in Processes (POB)”.

This post explains the instrumentation of the Procurement process (Procure to Pay) on item level.

The previous posts of the series have given an overview, described the architecture, explained the setup of the component.

In this blog, we will look at the sample content delivered for the instrumentation of the procurement process on the item level. We assume that Process Observer is already set up in your system. The sample process definition PROCURE_TO_PAY (Procurement to Payment), and the sample instrumentation needed for the same are delivered in the following releases. (Refer SAP Note 1813249).

ERP 6.0 EhP4 (SAP_BS_FND 701 SP14, EA-APPL 604 SP14)
ERP 6.0 EhP5 (SAP_BS_FND 702 SP12, EA-APPL 605 SP11)
ERP 6.0 EhP6 (SAP_BS_FND 731 SP08, EA-APPL 606 SP08)
ERP 6.0 EhP6 (SAP_BS_FND 747 SP02, EA-APPL 617 SP02)

As the process definitions are defined as normal customizing, you may need to check that the POB customizing is copied from client 000 to your current client.

To follow the exercises in this blog, it may be useful to have a copy of composite role SAP_POC_BPX assigned to the user, with appropriate authorization settings in the profile.

In the following, we are only going to look at the example for procurement processing. A typical procurement process in the SAP system is as shown below. We will concentrate on the ERP side of this process in the blog.

In order to monitor the process, we need to define the process in the POB. Each box in the above diagram represents an activity, often referred to as “process step”, in the procurement process definition (PROCURE_TO_PAY). The definition is at this point not linked to any runtime object. So the next step is to link the definition, or “model”, to the runtime. To do that, you have to assign (at least) one task (event) to each activity. At runtime, the events are mapped to the activities.. You can create new tasks in the POB façade layer. In this blog we’ll describe how to do this.

The sample Process Definition PROCURE_TO_PAY helps to monitor the above procurement scenario. This process definition is pre-configured with the following KPIs.

Count KPIs

Number of Purchase Order (line item) changes
Number of PO(line item) changes before PO Send
Number of Purchase Order Releases
Number of Changes in the Purchase Requisition Item
Number of Quantity Changes in Purchase Requisition item
Number of Purchasing Group changes in Purchase Requisition
Number of Purchase Requisition Delivery Date Changes
Number of Purchase Order Price Changes
Number of Schedule Line Quantity Changes in a Pur.Order Item
Number of Schedule Line Delivery Date Changes in a PO item

Duration KPIs

Cycle Time for Purchase Order approval
Cycle Time for Purchase Order line item creation to invoice date
Cycle Time for Purchase Requisition item creation to Purchase Order Creation
Cycle Time for Purchase Requisition item creation to Purchase Order Sending
Purchase Order sending to Goods Receipt
Cycle Time for Purchase Requisition item creation to Goods Receipt
Process Cycle Time (The time taken for the completion of the process)
Cycle Time for Purchase Requisition release to Purchase Order approval

Application Façade

The application façade encapsulates the entities at the runtime to put them at the disposal of the process definition. The entities in this layer are created to support requirements of the process definition. Only the entities of the runtime which are relevant for the processes are created in the façade.

Tasks represent the BO activity of the runtime in the façade. The tasks are maintained in the façade layer using the customizing node Maintain Objects in Façade Layer.

Note: You could use the transaction POC_FACADE also.

SOA BO Types

The Node SOA BO Types contains the whole list of business object types (BO Types) delivered by SAP. Check whether the BO Type is exists already; else create a new one by clicking New Entries button.

In the example we have taken, there are four BO types involved:

Purchase Request
Purchase Order
Goods Receipt
Supplier Invoice

Business Object Type

From the SOA BO Types, we select the BO types which we need to use in the scenario we have chosen and maintain in the node Business Object Type node. Click the button New Entries and create the BO Types. The result would look like this:

Task Type

Task type represents the action. For the procurement process definition we have provided the appropriate task types. For example, in order to represent the field level changes also the task types are defined.

Task

A task represents the event of a BO type. For example,the ‘Creation of a Purchase Order item’ is a task. It is essentially the BO Type + Task type.

The check box item level task is very important. This enables us to identify the item level information of the business object and log this information in process observer.

You can create new tasks by clicking the button New Entries.

The different tasks needed for the example definition PROCURE_TO_PAY are as shown below:

Callable Business Entity Type

One of the easiest means to describe a business process is the screens, or in SAP terms, the transactions you use for the different steps of the process. The callable business entity is “the transaction”, but it can also be a web service call or work flow step. In the node Callable Business Entity Type, you define the transaction you use for your process step. Click on the button New Entries to create new entries.

The result would be as given below:

Process Definition Viewer

Using transaction POC_VIEWER from the SAP Easy Access Menu, or entering directly as transaction code, you can open the Process Definition Viewer.

The complete list of activities of the process definition PROCURE_TO_PAY is shown in the diagram below.

‘Create Purchase Requisition (Item)’ and ‘Create Purchase Order (Item)’ are both marked as start activities. This means that, either of these can create a new process instance in the process log. However, a new process instance is created for a ‘Create Purchase Order (Item)’ only if there are no preceding purchase requisition.

You can also find count and duration KPIs that will then be determined at process instance level, and will be available for process monitoring and for process analytics:

To start logging, you have to set the log level for ‘Sales Order Processing’ to ‘Standard Logging’, using transaction POC_MODEL (Create/Edit Process Definition).

Now run your process, starting from purchase requisition. You can use the following transactions in the system:

Create / Change Purchase Requisition - ME51N/ ME52N
Create / Change Purchase Order - ME21N/ ME22N
Goods Receipt - MIGO
Create Supplier Invoice - MIRO

Make sure to create all objects with reference to the predecessor objects. Without those references the process would not work from business perspective! The references will make it possible for POB to determine the process chain. Note that if you add references to predecessor objects after creating the object itself would mean that the creation is not part of this process instance.

Logging the events for Procurement Scenario

The following sample BAdI implementations/ reports are provided in order to help the logging of the different events of the procurement scenario.

Purchase Requisition (Item):

BAdI : ME_REQ_POSTED

Sample Implementation Name : IMP_POC_A_REQ_POSTED

Class : CL_POC_A_REQ_POSTED_SAMPLE

In the BAdI implementation the direct event API (Function Module: POC_RAISE_EVENT) is used to throw the events as follows:

108 / 901 Create PR line item
108 / 903 Change PR line item
108 / 911 Change PR purchasing group
108 / 912 Change Purchase Request item 'Quantity'
108 / 914 Change Purchase Request item 'Delivery Date'
108 / 904 Delete PR line item
108 / 905 Release PR line item

Purchase Order (item)

BAdI : ME_PURCHDOC_POSTED

Sample Implementation Name : IMP_POC_A_PO_POSTED

Class : CL_POC_A_PO_POSTED_SAMPLE

In the BAdI implementation the direct event API (Function Module: POC_RAISE_EVENT) is used to throw the events as follows:

001 / 21 Create PO
001 / 901 Create PO line item
001 / 903 Change PO line item
001 / 913 Change Purchase Order item 'Price'
001 / 915 Change Purchase Order item 'Indicator for final delivery'
001 / 916 Change Purchase Order item 'Indicator for final billing'
001 / 917 Change Purchase Order item 'Schedule quantity'
001 / 918 Change Purchase Order item 'Schedule delivery date'
001 / 904 Cancel PO line item
001 / 4 Approve PO

Send PO

Report Name: POCAR_RAISE_EVENT_SEND_PO to raise the event 001 / 921 (Send PO)

We take the messages from DB table NAST (Message framework table) for all the Purchase orders (KAPPL = ‘EF’) which are “Successfully

Processed” (VSTAT = ‘1’). We take only those entries which are not yet processed (by comparing the dates/times using DATVR and UHRVR fields)

Goods Issue

BAdI : MB_DOCUMENT_BADI

Sample Implementation Name : IMP_POC_A_DOCUMENT

Class : CL_POC_A_DOCUMENT_SAMPLE

Method : MB_DOCUMENT_UPDATE

In the BAdI implementation the direct event API (Function Module: POC_RAISE_EVENT) is used to throw the events as follows:

467A / 901 Create Goods Receipt
467A / 10 Cancel Goods Receipt

Supplier Invoice

BAdI : INVOICE_UPDATE

Sample Implementation Name : IMP_POC_A_INV_UPDATE

Class : CL_POC_A_INV_UPDATE_SAMPLE

Method : CHANGE_IN_UPDATE

In the BAdI implementation the direct event API (Function Module: POC_RAISE_EVENT) is used to throw the events as follows:

127 / 901 Create Supplier Invoice item
127 / 904 Delete Supplier Invoice item

Process Monitor

Now, we will have a look at process monitor to see the process. There are two ways you can enter the process monitor. You can either access it directly, choosing ‘Process Monitor’ from the SAP Easy Access Menu (see above), or by entering transaction code POC_MONITOR.

To see the activities (steps) of the process instance, you could either double click on the instance or click on the Process Details button after selecting the process instance row. In the process details screen you will find all the activities, with the last activity at the top. The related activities are displayed at the below part of the screen for each of the activity.

You can also find the different KPI values in the monitor.

We hope that this blog about the instrumentation of the procurement to payment process on item level will help you to track the process easier .

Stay tuned for more news on Process Observer!