Skip to Content

The replenishment lead time represents the total period of time which is required to procure or manufacture an item. The replenishment lead time is mainly used by the availability check to calculate the material availability date. In order to enable the calculation of the replenishment lead time for availability check, the field ‘Check without RLT’ (V_441V-OWBZP) in the scope of check (transaction OVZ9) must be empty.

OVZ9_1.jpg

RLT calculation is performed in form END_OF_RLT_CALCULATE which is called from function module AVAILABILITY_CHECK / form AVAILABILITY_CHECK_R3.

RLT_1.jpg

Key variables:

S_MTWZT = In-house production time

S_WEBAZ = GR processing time

P_ATPMATX-PLIFZ = Planned delivery time

P_ATPMATX-WZEIT = Total replenishment lead time

P_ATPPLANTX-BZTEK = Purchasing processing time

S_FKDAY = Factory calendar day

S_GKDAY = Gregorian calendar day

1 – Calculation of the Replenishment Lead Time in case of externally procured materials ==> Material Master, MRP 2 view, Procurement type (field BESKZ) = F:

For externally procured materials, the replenishment lead time gets calculated based on:

  •   the purchasing processing time (transaction OPPQ, Material Planning Run section, External Procurement button, field BZTEK)
  •   the planned delivery time (transaction MM02, MRP 2 view, field PLIFZ OR transaction ME12, Purch.org.data 1 view, field APLFZ)
  •   the GR processing time (transaction MM02, MRP 2 view, field WEBAZ).

In case of the purchasing processing time, the system considers factory calendar days, a.k.a working days of the plant.

In case of the planned delivery time, the system considers standard calendar days.

In case of the GR processing time, again the system considers factory calendar days (working days of the plant).

The sequence of RLT calculation is:

  •   1st = purchasing processing time
  •   2nd = planned delivery time
  •   3rd = GR processing time.

EXAMPLE 1:

Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

Purchasing processing time = 2 days

Planned delivery time =  5 days

GR processing time = 3 days

Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:

09.03.2015 (Monday) – Requested delivery date

10.03.2015 (Tuesday) – Purchasing processing time | DAY 1

11.03.2015 (Wednesday) – Purchasing processing time | DAY 2

12.03.2015 (Thursday) – Planned delivery time | DAY 1

13.03.2015 (Friday) – Planned delivery time | DAY 2

14.03.2015 (Saturday) – Planned delivery time | DAY 3

15.03.2015 (Sunday) – Planned delivery time | DAY 4

16.03.2015 (Monday) – Planned delivery time | DAY 5

17.03.2015 (Tuesday) – GR processing time | DAY 1

18.03.2015 (Wednesday) – GR processing time | DAY 2

19.03.2015 (Thursday) – GR processing time | DAY 3

Based on the above described calculation the end of replenishment lead time will be 19.03.2015.

EXAMPLE 2:

Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

Purchasing processing time = 2 days

Planned delivery time =  3 days

GR processing time = 3 days

Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:

09.03.2015 (Monday) – Requested delivery date

10.03.2015 (Tuesday) – Purchasing processing time | DAY 1

11.03.2015 (Wednesday) – Purchasing processing time | DAY 2

12.03.2015 (Thursday) – Planned delivery time | DAY 1

13.03.2015 (Friday) – Planned delivery time | DAY 2

14.03.2015 (Saturday) – Planned delivery time | DAY 3 —–> The system performs an extra check to see whether the end date of the planned delivery time is a working day at the plant. If it is not, the end date of the planned delivery time will be moved to the next possible working day.

16.03.2015 (Monday) – Planned delivery time | DAY 3

17.03.2015 (Tuesday) – GR processing time | DAY 1

18.03.2015 (Wednesday) – GR processing time | DAY 2

19.03.2015 (Thursday) – GR processing time | DAY 3

Based on the above described calculation the end of replenishment lead time will be 19.03.2015.

2 – Calculation of the Replenishment Lead Time in case of internally produced materials ==> Material Master, MRP 2 view, Procurement type (field BESKZ) = E:

For internally produced materials, the replenishment lead time gets calculated based on:

  •   the in-house production time (transaction MM02, MRP 2 view, field DZEIT)
  •   the GR processing time (transaction MM02, MRP 2 view, field WEBAZ)
  •   OR the total replenishment lead time (transaction MM02, MRP 2 view, field WZEIT).

In case of all the above mentioned figures, the system considers factory calendar days, a.k.a working days of the plant. If the total replenishment lead time (field WZEIT) is maintained, and the in-house production time (field DZEIT) or the GR processing time (field WEBAZ) are also maintained, the system will only take the total replenishment lead time into consideration.

The sequence of RLT calculation (if the total replenishment lead time is not maintained) is:

  •   1st = in-house production time
  •   2nd = GR processing time.

EXAMPLE 3:

Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

In-house production time = 3 days

GR processing time = 2 days

Total replenishment lead time = 0 days

Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:

09.03.2015 (Monday) – Requested delivery date

10.03.2015 (Tuesday) – In-house production time | DAY 1

11.03.2015 (Wednesday) – In-house production time | DAY 2

12.03.2015 (Thursday) – In-house production time | DAY 3

13.03.2015 (Friday) – GR processing time | DAY 1

16.03.2015 (Monday) – GR processing time | DAY 2

Based on the above described calculation the end of replenishment lead time will be 16.03.2015.

EXAMPLE 4:

Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

In-house production time = 3 days

GR processing time = 2 days

Total replenishment lead time = 8 days

Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:

09.03.2015 (Monday) – Requested delivery date

10.03.2015 (Tuesday) – Total replenishment lead time | DAY 1

11.03.2015 (Wednesday) – Total replenishment lead time | DAY 2

12.03.2015 (Thursday) – Total replenishment lead time | DAY 3

13.03.2015 (Friday) – Total replenishment lead time | DAY 4

16.03.2015 (Monday) – Total replenishment lead time | DAY 5

17.03.2015 (Tuesday) – Total replenishment lead time | DAY 6

18.03.2015 (Wednesday) – Total replenishment lead time | DAY 7

19.03.2015 (Thursday) – Total replenishment lead time | DAY 8

Since the total replenishment lead time field is maintained, the system will not take the in-house production time and the GR processing time into consideration, so the end of the replenishment lead time will be 19.03.2015.

3 – Calculation of the Replenishment Lead Time in case of materials maintained for both procurement types ==> Material Master, MRP 2 view, Procurement type (field BESKZ) = X:

If a material is maintained for both procurement types, during RLT calculation the system will consider it as a material, which is internally procured. This means that the purchasing processing time and the planned delivery time will not be taken into consideration, not even if these are the only RLT relevant fields maintained.

To report this post you need to login first.

10 Comments

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

  1. bijay kumar

    Hi Andras,

    I read your “checking material availability” article.Like the previous article,This article also very much informative.

    Keep sharing such valuable article,by which we the community member get a lot of information.

    Regards

    Bijay

    (0) 
  2. Kundan Vishwakarma

    Hi Andras, I had gone through your document, and need to clear my doubt. I tried the same scenario in my case but it is not working, The issue or my doubt is that, i have created new product which IN-HOUSE procurement i.e. internal  with zero inventory exist for the same. I update the data as per requirement under below snap shot, Now the system should calculate in such way that, suppose, Order is created in today’s date i.e 20.08.2016 and CRD date is also same 20.08.2016. The scenario exist in two ways, Example 1: CRD 20.08.2016 In-House Date 21.08.2016 In-House Date 22.08.2016 In-House Date 23.08.2016 GR processing time 24.08.2016 GR processing time 25.08.2016 So MAD should be or confirmed Qty date should be 25.08.2016, but it is taking 26.08.2016. As 20.08.2016 and 21.08.2016 should be holiday. (only if holiday should be assume as working days in this scenario). Example 2: CRD 19.08.2016 Friday Holiday 20.08.2016 Saturday Holiday 21.08.2016 Sunday In-House Date 22.08.2016 Monday In-House Date 23.08.2016 Tuesday In-House Date 24.08.2016 Wednesday GR processing time 25.08.2016 Thursday GR processing time 26.08.2016 Friday In this case saturday and sunday is consider as holiday, so CRD date 19.08.2016 so MAD date should be 25.08.2016, but it is taking same 25.08.2016. Why ? Could you explain me the above scenario calculation for the above RLT & ATP. Nothing has been maintained in anywhere in config. Kindly suggest why….? Thanks in advance. Regards, Kundan

    (0) 
    1. Andras Gabor Csepregi Post author

      Hello Kundan,

      in order to answer your query I would have to take a closer look on your system (customizing, master data, calendar settings, etc.). But you can also try to figure the calculation part out by checking form END_OF_RLT_CALCULATE. This is where the calculation is carried out, so all you need to do is go to the debugger and see what is happening there.

      Please also make sure that your time stream is correct. The time stream is actually a table which contains all the working days / time intervals of a shipping point. Sometimes it can happen that the time stream is inconsistent, so you need to delete it manually. The time stream will be regenerated automatically by the system next time a scheduling is carried out. For more information on this, please consider SAP KBA 1579665.

      Thanks & regards,

      Andras

      (0) 
  3. Vegard R

    Hello Andras,

    Thank you for this article – helpful indeed!

    I was wondering if you have any tips, advice, can and can-not’s about this scenario:

    The Purchasing Processing Time is maintained at plant-level from what I understand. But is there a way to make the processing time dynamic through a calendar of sorts?

    Example:

    We buy a material through external procurement from a fixed vendor on a fixed weekday (every Monday), some materials even every other week. Is there a way that we could replace the Purchasing Processing Time (PPT) with a calculation?

    If I place an order on a Tuesday, the currently rigid PPT of 3 days in our system, SAP thinks we’re going to purchase the product on Friday, and not Monday.

    There’s the Planning Calendar function in MRP2 for instance, is it possible to get SAP to include the calendar in the lead time?

    Hope to hear from you 🙂

    (0) 
    1. Andras Gabor Csepregi Post author

      Hello Vegard,

      unfortunately in the standard system there is no option to get the purchasing processing time dynamically calculated. As you also mentioned, the purchasing processing time is maintained at plant level (in transaction OPPQ), and it is a constant value.

      If you want to have some kind of a calculation for this value, you will need to add your own logic through some enhancement points. I was working on a customer incident a couple of months ago where the customer implemented his own RLT logic in an enhancement point that was called right at the begging of form END_OF_RLT_CALCULATE. Needless to say, implementing such a custom logic should be carried out with appropriate care. If you decide to go down this path, please make sure that the newly created functionality is tested thoroughly. Also, carrying out such a change is a system modification, therefore SAP Product Support will not be able to help you if something goes wrong. In this case you will need to get the assistance of your ABAP consultants / technical team.

      Best regards,

      Andras

      (0) 
      1. Vegard R

        Hello, Andras.

        Thank you for the clarification!

        I just have to ask tho, you’re absolutely certain that it can’t be done in SAP standard? I always thought that the availability check is simulating an MRP run somehow, but I guess not then.

        And how does transfer of requirements (TOR) fit into this picture?

        Sorry for these questions, I just like how you explain things and you’re clearly clever 🙂

        (0) 
        1. Andras Gabor Csepregi Post author

          Hello Vegard,

          ATP check is not simulating an MRP run, it just checks the stocks, the receipt elements, and the issue elements (based on the scope of check – transaction OVZ9) and makes quantity confirmations. MRP is a different story.

          The transfer of requirements basically controls which requirements should be visible in table VBBE and VBBS. An MRP run can be executed for those requirements which can be found in these two tables (of course, this is not 100% true, there are some fine tuning options that can result in a different system behavior). Also, those requirements which are stored in VBBE and VBBS are considered by the ATP check. For more information on the transfer of requirements, please consider SAP KBA 2041268.

          Best regards,
          Andras

          (0) 

Leave a Reply