ATP Bucket Strategy

This blog gives details of the ATP bucket configuration steps in SAP-APO GATP functionality.

ATP buckets and the ATP bucket strategy logic provide the flexibility to change confirmation situation of orders in a day to align with the business need. For example, if the business wants to create deliveries today with a conservative strategy, it would not be able to use the receipts that are falling in today’s bucket. Today’s receipts in this case would only be considered tomorrow in the ATP calculation. Bucket can also be used to change the time to be based on pick / pack times, etc. There can be situations where some Distribution centers depend on the replenishments from production plants and they need to align the time of confirmation of orders based on the time at which receipts arrive into the DC.

This can be achieved by using a combination of ATP bucket logic, issue limits, and shift receipts. Synchronous and Asynchronous buckets are nothing but a combination of these parameters and hence can be used for the similar purpose.

In an ATP time series, receipts, requirements and stock elements are managed in aggregated (time-based) form. ATP Buckets help in checking the product availability. ATP buckets are used to define the exact time when the ATP quantity of the receipt elements will be available for consumption by the issue elements. The ATP quantity remains constant throughout the bucket. It consists of issue limits and receipt shifts. The standard bucket size is 1 day.


SAP APO Configuration: ATP Buckets

SPRO Path:

/wp-content/uploads/2014/11/1_590392.png

ATP buckets are configured as below:

/wp-content/uploads/2014/11/2_590396.png

Bucket ID: Character value defining the ATP bucket

Short text for bucket ID: Description of the bucket

Issue Limit: You specify the time here at which the bucket limit for issues lies in the ATP time series. Here we have to position the limit such that it lies at a time with few issues.

Shift Receipts: The limit of the receipt bucket determines the time at which the receipt elements are valuated. This time is shifted back from the issue bucket limit to arrive at the receipt bucket limit. You can achieve synchronous ATP time series for receipts and issues by shifting by 0 hours, and asynchronous ATP time series using a value between 0 hours and 24 hours.

For example: The limit of the issue bucket is at 06:00 UTC; the receipts are shifted 4 hours. Receipt elements and concurrent requirements are thus valuated in the product availability check at 02:00 UTC.

Local Time: If checked, all issue elements for all locations will be evaluated in local time zone. It not, they will be evaluated in UTC time.

Number of buckets/day: The standard value is 1. It means that the product availability check is exact to the limit of one day.

Distribution Key: If this indicator is set, finished products are incorporated proportionately to the daily produced quantity according to planning. It will control finished products of process orders that stretch over several days into ATP time series.

Bucket TS: This defines how ATP time series are evaluated in the product availability check. The following options are available for valuating receipt buckets:

  • No Restriction: The time series can be used for all ATP groups.
  • Progressive Logic Only: The time series are set up specifically for the progressive logic.
  • Conservative Logic Only: The time series are set up specifically for the conservative logic.
  • Exact Data Only: The time series are set up specifically for exact data. The bucket boundaries are relevant, for example, for grouping several partial confirmations on the same day.

The logic for the above is as follows:

  • Conservative logic: Receipts valuated at the end of the receipt bucket to get the ATP quantity. Issues are always at the start of bucket.
  • Totally Conservative logic: Receipts valuated at the end of the receipt bucket to get the ATP quantity, but cannot confirm between the start of an issue bucket and the end of the receipt bucket. Issues are confirmed at the end of receipt bucket at the earliest.
  • Progressive logic: Receipts are valuated at the start of the bucket to arrive at ATP quantity. Issues are always at the start of bucket.
  • Exact logic: This does not take into account time series. Receipts and issues are considered as and when they arrive.

Depending on the business need, the logic can be chosen. For example, if the receipts coming in the later part of the day can still be used in business cases where

Example:

Bucket Limit Issues

Shifting of Receipts

Time at which element is available

Comment

00:00:00

0 hours

00:00:00

Postponement of receipts by 0 hours

06:00:00

04 hours

02:00:00

Postponement of receipts by 4 hours

/wp-content/uploads/2014/11/3_590397.png

In the second example, the issue coming in at 07:00 hours today will be evaluated at the start i.e. 06:00 hours. It will try to confirm this issue according to the receipts in the receipt bucket. Receipt coming in at 09:00 hours will be evaluated at the end of the bucket, i.e. 02:00 hours tomorrow. And hence, the earlier issue element will be confirmed at the end of the receipt element at 02:00 hours tomorrow.

After the ATP buckets configuration is done, the Bucket IDs are assigned to the ATP Group in SAP APO – SPRO. Below is the navigation path to do the assignment of the bucket ID to the ATP Group.

/wp-content/uploads/2014/11/4_590398.png

/wp-content/uploads/2014/11/5_590399.png

From the Easy Access screen, go to Tcode: /sapapo/mat1. Enter Product and Location, and display the ATP tab.

/wp-content/uploads/2014/11/6_590400.png

The ATP group is read from the product master at run time. The ATP group is equivalent to the Checking Group in the ERP system.

Parth Soneji

To report this post you need to login first.

11 Comments

You must be Logged on to comment or reply to a post.

    1. Parth Soneji Post author

      Hi Hariharan

      Please post your queries as a discussion in the right forum and I will try to answer. The SCN forum has a practice of having discussion and not one-to-one communication so that other users can also benefit from the discussion.

      Parth Soneji

      (0) 
  1. Hariharan Iyer

    This is the screenshot from the product view. As seen, the demand and receipt is tied on the same date.

    Here we are doing ATP for deployment orders also, hence this example.

    /wp-content/uploads/2014/12/a1_604882.png

    This is the ATP bucket setting..

    A2.png

    Now check in ATP view

    A3.png

    The demand is before the receipts, so it will not confirm.

    I tried playing around with settings.. but couldn’t figure out the right one. If I use ”issue limit” as 23:59:59, it works for this case but sales orders get pushed out a day earlier and this wont work too..

    /wp-content/uploads/2014/12/a4_604951.png/wp-content/uploads/2014/12/a5_604952.png

    Seen above, the deployment and receipts are fine, but sales order has gone one day earlier and business will not like it..

    Any idea, what you have done or u have similar issues.

    Thanks

    Hari

    (0) 
    1. Babu Kilari

      Hello Hari,

      You should post such queries as a question in the forums. Please keep this in your mind for your subsequent posts. For your scenario -> you can use Rule Based Availability (No need to have substitution procedure attached because dummy rule can also work ) with a Calculation Profile having a delay of 24 hours to see the receipt at the end of the bucket. Calculation Profile works as a trigger to look for the possible reciepts with a horizon time defined in it. Hope this helps

      Babu Kilari

      (0) 

Leave a Reply