It works fine for me….but, and that is a big BUT….It only works off of the lead time for that level, plus the longest cumulative leadtime (not manufactured or expected) for the single component below that level.  So you have to have performed the calculation either across the whole site or from each level below the main item and up through the product structure.  The problem is that it is the sum of two numbers only.  The parent item at the level you are checking and the one other child item at whatever level that happens to be the longest AND has been calculated with the same function.  This to me is a wholly useless calculation - thus the reason we don’t use it - because what you really want (or are expecting) is that it is the leadtime of each level summed up through the entire structure, but that isn’t how the calc works.  So...it does work for me (V9 UD13), but it isn’t what I expect or want, so don’t use it.

Ahh!  That’s it!  I was assuming the calculation would consider the purchasing lead time for non-manufactured parts. 

So the bigger question is, if you run the calc for all parts why wouldn’t each level in a BOM roll up individually why wouldn’t it provide a summed total?   One would think each level would flow up with the longest component lead time in the level below….  

You will get better numbers if you do the whole site as each level will be done, but according to my checks, if you have a 6 layer structure, it doesn’t add up the cumulative lead time of all 6 layers as you would expect (by the name of the field and function).  It will be only whatever level you are looking at plus the longest level of any of the lower items.  

Why?   I couldn’t explain because to me it is illogical.

That is not very helpful, and could be potentially damaging if you don’t know the calculation is flawed….  Do you know if there are any plans to correct it the functionality?

Hi!

The APICS definition of Cumulative lead time is: The longest planned length of time to accomplish the activity in question. It is found by reviewing the lead time for each bill of material PATH below the item; whichever path adds up to the greatest number defines cumulative lead time.

And we do add the manufacturing lead time of the top part itself to the cumulative lead time. To put into a simpler form: Cumulative lead time is the longest sequence in the product structure defined in time.

So as an example, consider below simple structure:

A - manuf lead time 2 days

• B - purchase lead time 20 days
• C - manufacturing lead time 10 days
  • D - purchase lead time 9 days

Cumulative lead time for part A is: 20 + 2 = 22 days

Cumulative lead time for part C is: 10 + 9 = 19 days

And yes, it is a very theoretical value indeed, perhaps it makes sense in a pure Make-To-Order environment.

In many cases you have safety stocks and/or buffer stocks in the BOM that makes this calculation theoretical.

When I test this as I write this late evening in Sweden on an Apps10 database values looks fine according to above formula.  You must have performed the Purchase Lead Time calculation and the Manufacturing Time calculation prior you run the Cumulative Lead Time calculation. And I always perform the Cumulative Lead Time calculation for a specific Site. 

Hope this helps!

Cheers

Hi, 

we are suffering a similar problem using calculation purchase lead time in Cloud surrounding. We have set up a combonation of supplier lead time and supply chain matrix from supplier to site, including different calendar settings (supplier calender as working week of 5 days, external transport calendar as a week of 7 days). 

In our example, the supply chain matrix is set up with 49 days (7 weeks), while the supplier for purchase part is set up with 60 days (12 weeks). When running the job “calculate purchase lead time” the result is a lead time of 119 days, whats perfectly wrong and not considering calendard settings. 

Unfortunately, the value coming from this calculation is transfered into the inventory part and will be considered for proposing a delivery date to customer in case of out of stock. 

As I learned from previous posts, as well as from IFS consultant, this is somehow works as designed. Is there any possibilty to make IFS use the calendar settings in order to have correct calculation of delivery date in the customer order? 

Cheers