BAAN 5.0b
BaanERP - Enterprise Planning
Lead Times 
Topic document: TP_5.0b_LeadTimes_version3		

Edition Control Chart	
Edition	Date	Status	Changes	Affected pages	
1.00		Initial			

					

					

					

					

Document Authorization	
	Prepared	Checked	Approved	
Name/Signature	Jos van den Berg	Rene Haarman		
Date	30-03-2000	04-04-2000		
Name/Signature	Jos Verrijdt			
Date	14-04-2000			
Name/Signature				
Date				
Name/Signature				
Date				
Name/Signature				
Date				
Name/Signature				
Date				

Document information
Document
•	Number	: TP_5.0b_LeadTimes_version3
•	Type	: Topic Document
•	Name	: Enterprise Planning
•	Author	: Jos van den Berg
•	Edition	: Version 3
•	Date	: 14-04-2000

© Copyright 2000 Baan Development B.V. The Netherlands
All rights reserved. No part of this publication may be reproduced and/or published by print, photoprint, microfilm, audiotape, electronically, mechanically or any other means, or stored in an information retrieval system, without prior permission from the copyright owner.

The information in this document is subject to change without notice and should not be considered as a commitment by Baan Development B.V.  No responsibility is assumed for any error, which may appear in this document.

Table of Contents
1.	Introduction	6
2.	Lead-time Components	7
2.1	Definition of Lead-time Components	7
2.2	Definition of Lead-time Horizons	8
3.	Calculation of Lead-times	9
3.1	Finish Date Calculation of Planned Orders	9
3.2	Calculation for Planned Production Orders	10
3.2.1	Calculation before fixed lead time horizon	11
3.2.2	Calculation after fixed lead time horizon	11
3.3	Calculation for Planned Purchase Orders	12
3.3.1	Calculation before lead time horizon, supplier selected	12
3.3.2	Calculation after lead time horizon, supplier selected	13
3.3.3	Calculation when no supplier selected	13
3.4	Calculation for Planned Distribution Orders	14
3.4.1	With the use of a carrier	14
3.4.2	Without the use of a carrier	14
4.	Planning Lead-times	15
4.1	Introduction	15
4.2	Conversion from days to hours	15
4.3	Calendar Use	16
4.4	All order types	19
4.5	Planned Production orders	19
4.5.1	Calendar use before fixed lead time horizon	19
4.5.2	Calendar use after fixed lead time horizon	20
4.6	Planned Purchase Orders	20
4.6.1	Before lead time horizon, supplier selected	20
4.6.2	After lead time horizon, supplier selected	20
4.6.3	No supplier selected	20
4.7	Distribution Orders	20
4.7.1	With the use of a carrier	20
4.7.2	Without the use of a carrier	20
5.	Summary	21

1.	
Introduction
Lead-time calculations in Enterprise Planning are crucial in reaching correct planning results and enabling a smooth coordination between sales, production, and purchase. This is the core function of a planning tool in general. Therefore this topic document is solely focused on lead-time calculations. The use of calendars is of course very much related to this topic, as they determine the dates based on the lead-time calculation.
In more detail, this document describes the way planned order dates are calculated within Enterprise Planning (EP) in BaanERP. The calculation of the planned order dates depends on a series of lead time components that are defined within as well as outside the EP package. The focus is on which lead-times are used, and how they are used.
The scope of this document is the lead-time planning as part of order planning (RRP). Order planning contains the simulation of orders to meet demand. Part of the simulation is the calculation of order dates, the simulation determines requirement for an item and generates planned orders with start and finish date. The calculation of these start and finish dates will be described. The requirement date is a given fact. Determination of this requirement date and other aspects like quantity are outside the scope of this document.
Calculation of start and finish date is in fact the planning of lead times. This planning contains three parts:
-	A list of the lead time components, these are the definitions needed to calculate the order dates.
-	The use of these components in order planning, how are the lead time components build up into total order lead times. 
-	The calculation of dates out of the lead times based on calendars.
As part of the lead-time calculation and planning is related to or shared with other packages, references to these packages will be made.

		

2.	Lead-time Components
2.1	Definition of Lead-time Components

Most of the lead-times are defined in other packages instead of EP. Planning should reflect calculation of orders at execution level as much as possible, therefore lead time components defined on execution level are used if available.
Below is the list of relevant lead times defined in BaanERP. Components are either used for production, purchase, or distribution calculations. Some components are used for all planned orders types.

Lead time component	Package		Unit	Defined in

Order lead time	Manufacturing		days	item production data
						(tiipd0501m000)
Operation setup time	Manufacturing		min	routing operations
						(tirou1502m000)
Operation run time	Manufacturing		min	routing operations
						(tirou1502m000)
Safety time (BP)	Order Management		optional	item supplier information
						(tdipu0510m000)
Intern. processing time	Order Management		optional	item supplier information
						(tdipu0510m000)
Supply time (item)	Order Management		optional	item purchase data
						(tdipu0501m000)
Supply time (BP)	Order Management		optional	item supplier information
						(tdipu0510m000)
Calculated lead time (BP)	Order Management		days	item supplier information
						(tdipu0510m000)
Supply lead time (Distr)	Enterprise Planning		days	supplying relations
						(cprpd7530m000)
Extra lead time	Enterprise Planning		days	plan item data
						(cprpd1500m000)
Safety time (item)	Common Data		days	item ordering data
						(tcibd2500m000)
Inbound lead time	Warehousing		optional	item data by warehouse
						(whwmd2510m000)
Outbound lead time	Warehousing		days	item data by warehouse
						(whwmd2510m000)
Transport time	Common Data *

*  the calculated transport time is based on the addresses of the warehouses/business partners, the distance tables, and the carrier involved

Only two lead-time components are defined in EP, for the following reasons: 
•		Supply lead-time for distribution orders, as this order type is only used in planning. That is why the lead time component is defined in the supplying relations. 
•	Extra lead-time, to provide a planning safety time, additional to the safety time on execution level.

2.2	Definition of Lead-time Horizons

Beside the lead-time components, two horizons are defined. These horizons enable different lead-time calculations for short term planning (detailed but time-consuming) and long term planning (rough but fast planning):

Lead time horizon	Package			Unit	Related To
Lead time horizon	Order Management		days	item supplier information
						(tdipu0510m000)
Fixed lead time horizon	Enterprise Planning		days	plan item data
						(cprpd1500m000)

3.	Calculation of Lead-times
3.1	Finish Date Calculation of Planned Orders 

When simulating orders in EP, orders are planned backward based on the requirement date. If no sourcing strategy has been defined, the default supply source in the plan item data determines the order type (production, purchase, distribution) of the planned order. Some lead-times components are used on general level, which means that they are valid independent of the order type. However, most lead-time components used are dependent on the order type.
Only the lead-time components “extra lead time” (plan item data), “safety time” (item ordering data), and “outbound lead time” (item data by warehouse) are used for lead-time calculation on all order types. With these three components, the planned finish date is offset from the requirement date. This is depicted below:

planned finish date

requirement date

item safety time

extra lead time	outbound lead time

	

All planned orders, offsetting finish date

Note: for following pictures, these three components will be referred to as ‘extra + safety + outbound’.
Note: the planned finish date in the picture above must be considered an “interim” finish date. In case of planned purchase orders, the “interim” finish date is further offset via the BP safety time and the inbound lead-time. In case of planned production and distribution orders, the “interim” finish date is further offset because of calendar logic (specified working hours).

Additional calculation rules:
•	When the flag ‘simulate within time fence’ is not selected, requirements within the time fence are regarded as part of the planned inventory on the time fence date. In this case the finish date is moved forward to the time fence date. The finish date cannot fall before the time fence, because the start date will then fall before the current date (because the time fence is usually based on the production lead-time). A signal will warn the planner that there is insufficient time left to plan the extra lead, safety time, and outbound time between the moved finish date and the requirement date.  
The same logic applies if the finish date falls within the time fence, while the requirement date falls outside the time fence. The finish date will be moved to the time fence date also in this case.
•	When the flag ‘simulate within time fence’ is selected, the time fence is no longer a time barrier. Then it is possible that the finish date falls within the time fence or even in the past.
•	If the parameter ‘Planned before Firm/Actual’ is not selected, the finish date is moved forward to the finish date of last firm planned order in time. If there are orders on execution level beyond this point in time, the finish date is moved forward to delivery date of the last shop floor order/purchase order in time (dependent on the default source of the item).
•	The finish date cannot fall before the scenario start date. It will then be moved forward to this date.

3.2	Calculation for Planned Production Orders

The order lead-time for planned production orders can be planned in two ways, depending on the field ‘fixed lead time horizon’ (session Plan Item Data “cprpd1500m000”). The purpose of this horizon is to plan detailed on the short term (before the fixed lead time horizon), and to gain performance on the long term (after the fixed lead time horizon). 
First the start date is estimated by planning the ‘order lead time’ (tiipd0501m000) backward. 
1.	If the estimated start date falls before the date set by the ‘fixed lead time horizon’, the order is planned with routing, routing operations and quantity. In that case the order lead-time is equal to the sum of the operation lead times.
2.	If the estimated start date falls after the ‘fixed lead time horizon’ date, the details are skipped. The fixed order lead-time is used to plan without looking for the routing and operations.

start date

offset to working day

order lead time

extra + safety
+ outbound

requirement date

finish date

Planned production orders 

Before the order lead-time is planned, the finish date is offset (moved backwards) by safety time, extra lead-time, and outbound time, and is finally placed on the first available working moment (determined by the appropriate calendar). So the ‘offset to working day’ box in the picture represents a switch between calendars. 
Example:
When EP offsets the ‘extra+safety+outbound’ lead-time components, this may result in a finish date of ‘Saturday, 13.00’, based on a certain enterprise unit calendar. Next, a different calendar (e.g. resource or department calendar) may offset the finish date to ‘Friday, 17.00’, since this is the last working moment prior to ‘Saturday, 13.00’. In Chapter 4 the use of calendars is explained in more detail.

3.2.1	Calculation before fixed lead time horizon

When the estimated start date falls before the fixed lead-time horizon, the production order lead-time is calculated based on the routing. Per item, a series of routings can be defined. Per item-routing combination, operations are defined. The selection of the routing can depend on the default routing code parameter, the order quantity, and effectivity dates of routings. 
The order lead-time consists of a series of operation lead times. For the calculation of operation lead times, routing operations information is required:
•	setup time
•	run time (per unit)
•	machine occupation
•	man occupation
•	task type
•	work center critical capacity
•	work center waiting time

If the task type is ‘machine’ and the work center critical capacity is ‘machine capacity’:
•		
•	Operation lead time = (setup time + run time * quantity) / machine occ + wait time

If the task type is ‘non-machine’ and the work center critical capacity is ‘man capacity’ :
•	
•		Operation lead time = (setup time + run time * quantity) / man occ. + wait time

3.2.2	Calculation after fixed lead time horizon

If the estimated start date falls after the ‘fixed lead time horizon’, the production order lead-time is always equal to the order lead-time from the Item Production Data session (tiipd0501m000), independent from the order quantity. 
The order-lead time in the item production data can be either automatically calculated or manually inserted. The calculation of this order lead-time can be performed in the session “update order lead-times” (tirou1202m000). By default, the calculation is based on the Economic Order Quantity (EOQ) defined in item ordering data. Only if the order method is ‘Fixed Order Quantity’ (FOQ), this quantity is used instead. This quantity is multiplied with the total routing lead-time (cumulative of the operation lead-times). The result is rounded into days, and updated to the item production data session.

3.3	Calculation for Planned Purchase Orders

The supplier for a planned purchase order is selected from the item supplier information session (tdipu0510m000), based on priorities and lot sizing rules.
On the item supplier information a ‘Lead time horizon’ is defined. This horizon has the same purpose as the fixed lead time horizon for planning production orders: to increase the performance of the planning run. When the planned finish date of the planned purchase order falls within the lead-time horizon, the order is planned with detailed lead-time components, otherwise the ‘calculated lead time’ as a total is used.

3.3.1	Calculation before lead time horizon, supplier selected

The finish date is offset by the “extra + safety + outbound lead-time”, and additionally the “inbound lead-time + BP (business partner) safety time”.  Reason is that the finish date is the planned receipt date that is communicated on the purchase order to the supplier. This date must not include the internal inbound time and the supplier safety time. The planned start date is calculated in detail, using the internal processing time, supply time, and transport time. 

transport time

BP supply time

extra +safety + outb.

 

inbound time 

start date

BP safety time

intern. proc. time

Req. date

finish date

Purchase with supplier, within lead time horizon

Note: An “interim” finish date is first calculated in Enterprise Planning by offsetting “extra + safety + outbound lead-time” from the requirement date. The final finish date is calculated in Purchase by further offsetting the inbound lead-time and the BP safety time from the interim finish date.
Note: The transport time is based on the distance between the ship-from business partner address, and the address of the receiving warehouse. The distance table for the transport mode ‘not applicable’ is taken.

3.3.2	Calculation after lead time horizon, supplier selected

If the finish date falls outside the ‘Lead time horizon’ of the supplier, then start date is calculated with ‘calculated lead time’, which is the sum of processing, supply, and transport time. 

BP safety	inbound time		time

extra + safety + outbound

calculated lead time

start date

requirement date

finish date

Purchase with supplier, outside lead time horizon 

3.3.3	Calculation when no supplier selected

If no valid supplier is found or the valid supplier has no capacity left, the purchase order is planned without a supplier attached. Then, only the supply time of the item purchase data is used. This supply time is a substitute for internal processing time, BP supply time, transport time, and BP safety time. The inbound lead-time is still used for offsetting the finish date besides the extra + safety + outbound time.

Inbound + extra + safety + outbound

supply time

finish date

start date

Req. date

Purchase without BP 

3.4	Calculation for Planned Distribution Orders

3.4.1	With the use of a carrier

Distribution orders are generated based on the supplying relations session (cprpd7530m000). If a carrier is provided in the supplying relations, transportation time is calculated with the distance between the warehouse address of the supplying item and the receiving item (default warehouse of the plan items involved). The carrier determines the transport mode used in the distance tables. 
Remark:
•	
finish date

requirement date

extra + safety + outbound

transport time

set to working day

If no distance is defined for the addresses, then calculated transport time is 0 (no warning is given).

start date

Distribution orders with carrier 

3.4.2	Without the use of a carrier

If no carrier is provided, the supply lead time in the supplying relation session is used instead.

start date

set to working day

supply time

extra + safety + outbound

requirement date

finish date

 

Distribution orders without carrier

4.	Planning Lead-times 
4.1	Introduction

Chapter 3 discussed the calculation of the total lead-times for production, purchase, and distribution orders. After the lead-times are calculated, they need to be converted into a planned start and finish date. Calendars are used to determine these planned dates, because they represent the working time of a particular entity (e.g. purchase office, work center). 

4.2	Conversion from days to hours

Most lead-time components are sometimes defined in days (see also list of components in paragraph 2.1). The planning however, is performed in hours. Therefore, the lead-time components must be converted from days into hours, after which the resulting number of hours are compared to the hours in the appropriate calendar. 
For converting lead-time duration from days into hours, Enterprise Planning uses the “basic capacity” of the resource that is defined as “company calendar provider” in the EP parameters session (cprpd0100s000). The basic capacity is user definable on the resource (cprpd2500m000) as a number of hours per day. 
Example Enterprise Planning:
An extra lead-time of 4 days is specified in plan item data. When converting this to hours, EP will select the appropriate calendar (in this case the calendar of the Enterprise Unit defined in plan item data) and check the basic capacity of the Company Calendar Provider:
-	Calendar with 16 hours availability per day, 5 days a week
-	Basic capacity on resource is 8 hours per day
The extra lead-time of 4 days is converted into hours by multiplying with the basic capacity. The result is 32 hours lead-time. This 32 hours is matched against the calendar with 16 hours per day. The result is an offset of 2 working days (32/16).  So, what appears to be a lead-time of 4 days is converted into an offset of 32 hours, which represents a 2 day offset in the calendar. 
Purchase however, uses a fixed conversion of 24 hours per day for converting its lead-time components into hours (refer to paragraph 2.1 to see the lead-time components per package).
Example Purchase (Order Management):
A business partner supply time of 1 day is specified in item supplier information. Suppose the ‘ship-from BP’ calendar has 8 hours availability per day, 5 days a week. The BP supply time is converted into hours by multiplying with 24 (fixed conversion factor). The result is 24 hours lead-time. These 24 hours are matched against the calendar with 8 hours availability per day. The result is an offset of 3 working days (24/8) according to the calendar. 
In the following paragraph all the conversions are listed for every lead-time component.

4.3	Calendar Use 

The list on the next page exactly states the calendars that are used on every lead-time component and on time fences and horizons.
However, first some very general rules that apply:
•	The calendar of the enterprise unit from the plan item data session (cprpd1500m000) is taken to offset the requirement date to the finish date of an order. 
Note: Conversions related to the enterprise unit calendar, use the ‘Basic capacity by Day’ of the resource that is defined as ‘Company Calendar Provider’ in EP Parameters (cprpd0100s000).
•	The calendars of the ship from BP and purchase office are taken to plan the start date for planned purchase orders. 
•	The calendar of the resource is taken to plan the start date for planned production orders. 

The table below shows the calendar and specifics used for every lead-time component:

It is possible to re-plan a planned order after changing the start- or finish date of the planned order. When changing the start date, a forward re-planning is performed. When changing the finish date, a backward re-planning is performed. The table below depicts the lead time components and related data that are used during backward and forward re-planning.

4.4	All order types

Safety time and extra lead-time use the calendar of the item enterprise unit. The warehouse outbound time is linked to a warehouse, therefore using the warehouse calendar.
The same holds for the warehouse inbound time, used in purchase and distribution orders, this is also planned with the warehouse calendar.

4.5	Planned Production orders

4.5.1	Calendar use before fixed lead time horizon

When planning with routing operations, each operation is linked to a work center. Retrieval of the calendar and capacity is performed via a search sequence:

Calendar retrieval by work center
1.	Resource calendar (session cprpd2500m000).
2.	Calendar of department related to work center (tcemm1524m00) 
3.	Enterprise unit of department 
4.	Company calendar.
5. 	Standard calendar template 

For step 2 and 3 first the basic capacity of the resource is used, if no resource data are available the basic capacity of the “company calendar provider” resource in the EP parameters is used. For step 3, 4, and 5 the basic capacity of the company calendar provider is always used.

Note: When the calendar on e.g. resource level is defined for only a particular time period, the calendar is extended with the standard calendar template outside that time period. The default availability type from the EP parameters is searched for in the standard template to determine the number of days per week. The basic capacity of the “company calendar provider” (EP Parameters) is then used to determine the hours per day.
Example: 
Resource calendar effective from 01.06 till 30.06, 4 days per week, 6 hours per day.
Default availability type connected to the standard calendar template from Monday till Friday (5 days per week). Basic capacity on company calendar provider is 8 hours. This means that before 01.06 and beyond 30.06 the standard calendar template extends the resource calendar with 40 hours per week (5 days * 8 hours).
Conclusively, when the first calendar that is found (e.g. on resource level) for a resource only covers a certain time period within the planning, EP does not search for the next calendar on a higher level (e.g. department or enterprise unit). Instead, the first calendar is extended for the entire planning period with the standard calendar template as explained in the example above.

4.5.2	Calendar use after fixed lead time horizon

When using fixed order lead-time, no routing is used and therefore no work centers are involved. Therefore, the calendar of enterprise unit is used.

Calendar retrieval by item
1.	Enterprise unit of item.
2.	Company calendar.

For both steps the basic capacity of the “company calendar provider” in the EP parameters is used. 
4.6	Planned Purchase Orders

4.6.1	Before lead time horizon, supplier selected
Internal processing uses the purchase office calendar, supply time uses the calendar of the ship from BP, the supplier safety time is planned without calendar.
Transport time is based on the loading (supplying) address, as the orders are planned backward. (When planning forward, the calendar of the destination address is used)
4.6.2	After lead time horizon, supplier selected
When planning the calculated lead-time no calendar is used.
4.6.3	No supplier selected
When no supplier could be selected for the planned purchase order, the item supply time is planned without using any calendar.

4.7	Distribution Orders

4.7.1	With the use of a carrier
Transport time works like in purchase planning. It is based on the loading (supplying) address.
4.7.2	Without the use of a carrier
For offset to working day and planning the supply time, the calendar of the working center of supplying relation is used, like for planned production orders. If not defined, the item enterprise unit calendar is used.

5.	Summary
Lead-time calculations are core functionality of a planning tool such as Enterprise Planning. The result of the lead-time calculations for planned orders is a planned start date and a planned finish date. The planned finish date is offset from the original requirement date by lead-time component, such as safety time and outbound lead-time. Then the start date is offset from the finish date with components that depend on the source of supply (production, purchase, or distribution). 
Of course, the start and finish dates are influenced by calendars that represent the working days of e.g. a resource or a supplier. E.g. if the lead-time calculation offsets to a Saturday (non-working day), the calendar will then offset to Friday (working day).  
Furthermore, the lead-time calculation can be performed in a detailed way, or in a more aggregated way. This is dependent on a horizon. After the horizon, the aggregated calculation is performed for performance reasons.
The components and calendars used in the lead time calculation are depicted below for planned production-, purchase-, and distribution orders.