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.
In our second example we look at an action which is not executed immediately but rather by an executor. In EWM world this ‘executer’ could be a background job or a user executing the task manually. Usually we do not execute right away in case the execution is not too urgent and/or the resources for execution are not available at the point in time (remember our dentist example). This saves system resources and accelerates processing from user perspective.
An example for such an action in EWM would be an invoice which is to be send to the customer after GI posting of the delivery. This action does not have to be executed right away as it is not time critical. A background job could process the action at a later point in time once sufficient system resources are available.
And that’s basically it. As mentioned above there are a couple of more functionalities and possible configurations which we ignored in our story here. Good luck while digging deeper into those topics!
Note: We hope you liked this post and could learn something out of it. In case you are interested to receive more information or direct support in regard to this topic please feel free to create a request or contact the author directly (contact details below).