Very interesting new ATP BADI
The parameter dependent safety stock (PASS) is a very interesting functionality introduced in SCM 5. In its standard form one can use the forecasted demand to calculate a safety stock requirement during the ATP process. But the calculation of the safety stock value can use any other logic we want if we use the extension BADI /SAPAPO/ATP_PSS.
The process flow is very simple:
1) In the sales order we make sure that all information need for the calculation is transfered to APO through the field catalogue.
2) In the BADI we calculate the value we want for the PASS.
3) The ATP introduced the PASS dummy requirement as the first requirement in the list .
4) The ATP information returned to the user shows the amount of PASS that was used (which the user should read as: there is this amount of product/capacity, but its reserved for other kind of orders)
5) At the end of the ATP process the PASS requirement is removed.
This functionality has many use cases. The one described in the documentation is quite typical. The company wants to keep some quantity always available for rush orders, so a PASS value is defined and the user exit changes the PASS value to zero when the order type is of type "rush order".
A slightly more complex use case is to use PASS to enforce the allocation quotas at the product availability level. Product allocation is decoupled from the product availability check in ATP, so if a customer has consumed all allocation for the current period the system will shift the availability date to first day of the next period. But it will still be consuming stock/receipts from the previous period if such elements exist. For example, in the picture bellow the red customer places two orders of 100 in month 1. Since he only has 100 of allocation in each month the second order date is shifted for the first day of month 2. But it still uses the receipt from month 1.
When the orange customer places an order of 200 on month 1 it fails. It is possible from the point of view of allocation, but since the red customer orders are both using the receipt of month 1 the system can only confirm the orange order in month 2.
This is the typical problem and with PASS this scenario can be improved. Based on the allocation data (quota and consumption) a PASS value can be calculated to protect the allocation receipts. That way, when the latter customers place their orders the system will still have both allocation and receipts to confirm the orders in the expected periods. The picture bellow shows the same process when using PASS to protect the open allocation of the orange customer.
A last remark on using PASS with the R3. The documentation makes a reference that it is only supported by CRM and it seems to be because there is no user interface to define the PASS type parameter that APO is expecting to receive from R3. But using the BADI APO_BAPI_BUS10400 we can change the parameters coming from R3 and, in this case, we just need to put something like:
The process flow is very simple:
1) In the sales order we make sure that all information need for the calculation is transfered to APO through the field catalogue.
2) In the BADI we calculate the value we want for the PASS.
3) The ATP introduced the PASS dummy requirement as the first requirement in the list .
4) The ATP information returned to the user shows the amount of PASS that was used (which the user should read as: there is this amount of product/capacity, but its reserved for other kind of orders)
5) At the end of the ATP process the PASS requirement is removed.
This functionality has many use cases. The one described in the documentation is quite typical. The company wants to keep some quantity always available for rush orders, so a PASS value is defined and the user exit changes the PASS value to zero when the order type is of type "rush order".
A slightly more complex use case is to use PASS to enforce the allocation quotas at the product availability level. Product allocation is decoupled from the product availability check in ATP, so if a customer has consumed all allocation for the current period the system will shift the availability date to first day of the next period. But it will still be consuming stock/receipts from the previous period if such elements exist. For example, in the picture bellow the red customer places two orders of 100 in month 1. Since he only has 100 of allocation in each month the second order date is shifted for the first day of month 2. But it still uses the receipt from month 1.
When the orange customer places an order of 200 on month 1 it fails. It is possible from the point of view of allocation, but since the red customer orders are both using the receipt of month 1 the system can only confirm the orange order in month 2.
This is the typical problem and with PASS this scenario can be improved. Based on the allocation data (quota and consumption) a PASS value can be calculated to protect the allocation receipts. That way, when the latter customers place their orders the system will still have both allocation and receipts to confirm the orders in the expected periods. The picture bellow shows the same process when using PASS to protect the open allocation of the orange customer.
A last remark on using PASS with the R3. The documentation makes a reference that it is only supported by CRM and it seems to be because there is no user interface to define the PASS type parameter that APO is expecting to receive from R3. But using the BADI APO_BAPI_BUS10400 we can change the parameters coming from R3 and, in this case, we just need to put something like:
METHOD if_ex_apo_bapi_bus10400~change_inputparamextern.
DATA: ls_req TYPE bapi10400req.
LOOP AT requirements INTO ls_req.
ls_req-safety_stock_parameter = 'P'.
MODIFY requirements INDEX sy-tabix FROM ls_req.
ENDLOOP.
ENDMETHOD.
posted by pvl at 9/28/2007
| 6 comments
