SytelineMaster

The purpose of the Lead Time Processor (LTP) utility is to calculate an item’s fixed and variable lead times using the operations that make up its current routing. The fixed lead time is expressed in days. The variable in hours and is the run time for 1 piece.
Basic Algorithm
If you answer "No" to the "Use WC Calendar" and "Use Offset Hours" options, the LTP totals the run time for each operation in the routing and posts the result into the item master variable lead time field. If the work center is machine or machine and crew scheduled, the machine hours are accumulated. If it is purely crew scheduled, the labor hours are used.
If you leave the Shift ID blank it totals the move, queue, setup and finish hours for each operation, divides the total by the default shop calendar average hours per day and posts the resulting number of days into the item master fixed lead time field.  If you enter a Shift ID, the move, queue and finish hours are divided by the average number of hours per day from that shift rather than the default shop calendar.  The Shift ID field was added for the fix to APAR 107859 in the SQL versions (SL7 and higher).     
The variable time is adjusted by the operation efficiency (lead time / oper eff / 100) and work center utilization (lead time / wc util / 100).
If an operation has a value in the "Fixed Sched Hrs" field, that figure is added to the fixed lead in place of using the setup and run time.
Item master lead times are used by a number of functions in the system. One of the most important is the MRP module’s passing of planned orders from parent to component. The date assigned to the material requirement is calculated as:
PLN due date – (((PLN qty * var lead) / default shop cal hrs per day) + fixed lead)
The "Use WC Calendar" and "Use Offset Hrs" options exist so that the system’s lead time calculations will be more accurate if your are using operation overlapping and multiple shop calendars with varying hours per day. The following explains the how using those two options will affect the calculations.
Use WC Calendar
The "Use WC Calendars" option was designed to handle the situation where the various operations in an item’s routing use work centers that are tied to different shop calendars that have a varying number of hours per day. If you do not use this option, the LTP uses the hours per day from the default calendar when converting the fixed hours to days.
If some of the operations in the item’s standard routing had more (or less) hours per day than the default calendar, the date MRP arrives at when passing planned orders will often be different than the date at which scheduling would arrive since scheduling considers the extra (or less) time available in those work centers.
If you answer yes to the option, the LTP factors in the variable length calendars by calculating a "calendar factor" for each operation that does not use the default calendar. This factor is calculated as:
(avg hrs per day from default cal / avg hrs per day from oper’s calendar)
The resulting figure is then multiplied by the fixed and variable times for the operation in an attempt to compensate for the extra hours available per day. e.g. if an operation that uses a 10 hour/day work center has 1 hour per piece of run and the default calendar has 8 hours, there will per .8 hours added to the cumulative variable lead time for the item than 1.
Use Offset Hrs
The "Use Offset Hrs" option gives you the ability to factor the operation offset hours into the lead time calculations. If you answer "No" to the option, the LTP simply accumulates the setup and run for each operation as described above. This assumes each operation starts when the previous finishes and gives no consideration to operation overlapping which MAPICS handles with the Offset hours field.
When you answer "Yes" to "Use Offset Hrs", the algorithm changes dramatically in an attempt to compensate for the overlap. When the LTP encounters an operation with offset hours it will deduct the previous operation’s fixed and variable times from the running totals and add in the current operation’s offset to the fixed running total.
Basically, this means that the system will assume that the current operation’s offset is the duration of the previous operation. It will NOT change the actual values in the move, queue, setup and run hours fields of the previous operation.
For example, suppose you have an item with a typical lot size of 100 with 3 operations, each with 1 hour per piece of run time. Operations 20 and 30 have offset hours of 10 which means the begin 10 hours after the start of the previous operation.
If you elect not to have the LTP consider offset, it calculates fixed hours of 0 days and variable lead of 3 hours. When MRP passes a planned order for 100 it uses 300 hours (100 * 3 hr var lead) which comes to 38 days. When the planned order is turned into a job, the scheduling system would use the offset and arrive at 130 hours which is 16 days. The results in MRP showing the materials being needed 21 days earlier when the planned order is being passed then it will when the job is created.
Since operation 30 "covers" all but the non-overlapped time of operations 10 and 20, the offset hours from 20 can be considered a fixed duration for 10 and 30’s offset can be considered a fixed duration for 20.. Since offset does not vary with quantity, it makes sense to store this offset as fixed lead time.
In this example, if you tell the LTP to consider offset it would use operation 20’s offset of 20 hours as fixed time for 10 and ignore 10’s variable time. It would then use 30’s offset and use it for 20’s fixed and ignore 20’s variable. This would result in variable lead if 1 hour (30’s variable) and a fixed lead of 3 days (30 / 8 = 2.5 rounded to 3).
For a planned order for 100, MRP would pass the order using:
(100 pieces * 1 hr var lead) + 3 days fixed = 16 days
Using these two options, there may be a small difference between MRP’s calculation and scheduling’s calculation but it will certainly be more accurate than if not using them. It is important to realize that MRP is a planning tool, not a scheduling tool and cannot be expected to be as precise as the scheduling algorithm. To have MRP "schedule" each planned order using the item’s current routing would not be feasible purely from a processing time perspective.