Understand SAP EWM

PPF (Post Processing Framework)

Note: This post belongs to the blog-series ‘Understand SAP EWM’. The purpose of these series of blog-posts is to explain the concepts of the core features of SAP EWM ppf in a simple way. We want to focus on the basic understanding rather than the smallest details.

PPF is not something that can be explained in an easy way. Thus, we will simply ignore some of the functionalities. But don’t worry – we will not miss the important ones. We will concentrate on the idea of giving you an understanding of the base functionality which helps you to go into detail if needed.

So let us start with the main components around a SAP PPF action

First of all we need an application area were objects can exist
Then we need an object based on which we want to do something
This ‘something’ is our PPF action. So we’ve already learned that a PPF action always belongs to a given object
The PPF action is attached to the object based on condition(s)
It is either executed right away or it needs an ‘Executer’ to take care of the execution. In both cases we might have a 2nd set of conditions here, which are independent from the scheduling but refer to the execution only. To reduce the complexity we will not go into detail in regard to these conditions as usually these so called ‘execution conditions’ are not used anyhow

As usual we are going to look into the real world before we explain further details from an IT perspective. Let us take something that everybody knows – The ‘Health’

So our application area is the health and our object is the human body:

In our first example the action is a treatment against a life threatening pain. Here we demonstrate how an SAP PPF action works which is setup to be executed immediately. Assume you have a car accident and you are injured. The treatment against this pain is an ambulance which is called to help you. So our schedule condition here is an injury which is causing life threatening pain. The action – the ambulance fixing your pain – is executed right away once it has been scheduled.

In our second example the action is a treatment against small pain. In this example the action is not executed immediately but rather by an executor at a later point in time. Imagine you feel a bit pain in your teeth which appears from time to time. This pain is disturbing but does not prevent you from doing your daily routines. Still you ask your doctor for an appointment as you want him to check what’s going on. The doctor will regularly check which patients are having an appointment and heal those patients. So our schedule condition here is the combination of a small pain and an appointment at the doctors (usually the doctors will not do anything without an appointment). The action itself is the doctor healing you. The execution does not happen immediately but only at the point in time when the doctor checks his calendar and sees that it is time for you to be treated.

We should mention here, that we could also consider the existence of an appointment as part of a condition for execution but as mentioned before we ignore such execution conditions here and in our example we would end up with the same result anyhow.

Now we go back to the system and take the delivery as an object instead of our body. So our application area is the part of the system which is processing the deliveries and our object is an outbound delivery.

In our first example the action is a report which is printing delivery notes. We want a delivery note to be printed once a delivery is fully packed at the packing work center. So our schedule condition is the status for packing on the delivery header. The action is executed right away as we want to attach the delivery note to one of the HUs of the delivery once packing is physically completed.