Reveal SAP EWM
Condition record determination for PPF actions
Within this blog post I take a look into the technical part of condition record determination for PPF action schedule and start conditions. So on a high-level I will basically answer the question about how to get from a condition record to a scheduled or executed action?
As a practical example I decided to take the determination in the context of action conditions for delivery documents. A very similar approach is valid for any other PPF application in EWM which is using condition records in order to schedule or start its actions (e.g. actions on Handling Unit, Physical Inventory Document or Warehouse Order -level in the area of the ‘Warehouse Management Engine’).
You can expect answers to the following technical questions within this blog post:
- Where does EWM call the condition record determination (some examples)?
- What needs to be done in order to implement a custom logic to consider additional fields?
- How does EWM compare the given object with the given condition records?
Logical flow of the process that I will tackle within this post:
Condition records in the context of PPF actions in EWM are being evaluated for schedule and start conditions. As the name says – these conditions decide whether a given action is to be scheduled at all and whether it should be executed right away or not. The logic behind those conditions is defined via implementations of the BAdi EVAL_SCHEDCOND_PPF (for schedule conditions) and EVAL_STARTCOND_PPF (for start conditions) respectively:
Important: Not only Z-conditions but also all standard conditions are delivered as implementations of those BAdis. E.g. SAP standard delivers around 90 classes using the interface of the scheduling BAdi:
As mentioned above, with this blog post I want to focus on how EWM implements conditions based on condition records. For this purpose it is neither relevant whether those records are evaluated in the context of a schedule or a start conditions. Nor is it relevant whether those records are being evaluated in the context of scheduling for the application area of ‘Warehouse Requests’, ‘Warehouse Management Engine’ or any other area. Of course the approach of collecting data ahead of reading the condition tables is slightly different but I will come to this once we reach that point. For now, let us concentrate on our example in the context of scheduling an action for a warehouse request.
We take the action for the automatic GR posting of inbound deliveries. Via transaction SPPFCADM we can find a filter value which is assigned to a PPF action. The filter is used during runtime in order to determine the relevant implementation of the BAdis shown above (so in case you want to implement your own scheduling logic, you only need to create a new implementation of the BAdi and assign a different filter value here):
Let us now have a detailed look at one standard implementation in order to understand how EWM evaluates the condition records:
Both (scheduling & start condition) use the same method to read the condition technique customizing. In the context of deliveries/warehouse requests this is class/method /SCWM/CL_DLV_PPF_CONF-EVALUATE:
There are lots of other examples for implementations where this method is being called but the one above should be enough for now to have a good understanding of the context. So what is our EVALUATE method actually doing here?
Looking at it from the outside, this method is responsible to fill its return variable rv_cv. The variable is filled based on the result of the condition record determination in the following way:
Subsequently, it decides about the value of the exporting parameter in the interface method of our BAdi:
That should be understandable already