| Production order lead-times (transfer batch quantity) |  |
| In Manufacturing you can plan the operations of a production orders in a successive way. In this case, an operation must have been finished for all the items of the order, before the next operation can start. However, you can also plan the routing operations of a production order in a semi-parallel way, which means that you define the amount of items for which an operation must have been finished as the time point on which the next operation can start, called a transfer batch quantity. To use a transfer batch quantity, select the Transfer Batch Less Than Production Batch check box in the Production Planning (tisfc0110m000) details session, and define a value in the Transfer Batch Qty field. ERP LN plans the production order lead-time somewhat differently if you use transfer batch quantities than when it plans the routing operations in a successive way. Figure 1-1 illustrates the method ERP LN applies to plan operations with a transfer batch quantity in a forward planning situation. Figure 1-2 illustrates the method ERP LN applies in a backward planning situation Note You cannot select the Transfer Batch Less Than Production Batch check box for an operation if you selected the Fixed Duration check box for the preceding operation. Of course, this is also impossible in practice: if you bake bread rolls in an oven, all the bread rolls must stay in the oven for the full fixed period time. Forward planning: normal situation Figure 1-1
QT | queue time
ST | setup time
RT | run time
WT | wait time
MT | move time
A | queue start date
B | setup + run start date
C | setup + run restart date
D | wait start date
E | move start date
F | queue start date (next operation)
G | setup + run start date (next operation)
Figure 1-1 shows a normal planning situation in which operation 20 starts at the time point on which operation 10 is finished for the entire production batch. However, the situation is not always as simple as this. The following sections describe how ERP LN plans the operations if a long operation is followed by a short operation, and you want to use the transfer batch quantity concept. Forward planning with transfer batch quantity Figure 1-2
QT | queue time
ST | setup time
RT | run time
WT | wait time
MT | move time
A | queue start date
B | setup + run start date
C | setup + run restart date
D | first transfer batch finished
E | wait start date
F | move start date
G | queue start date (next operation)
H | setup + run start date (next operation)
Figure 1-2 is a graphical reproduction of a forward planning situation in which you defined a product routing consisting of operation 10 and operation 20. For operation 10, you defined a transfer batch quantity. Figure 1-2 shows that ERP LN cannot always simply schedule the starting point of operation 20 (G) based on the time point on which the first transfer batch quantity rolls out of operation 10 (D). The figure shows that the run time (RT) of operation 20 is much shorter than the run time of operation 10. The oblique arrow indicates that a conflict occurs if ERP LN plans operation 20 after the first transfer batch is ready from operation 10. It would implicate that operation 20 is finished before operation 10 ends. Obviously, this can never be true. To avoid this unrealistic planning situation, the planning mechanism of ERP LN performs the following correctional steps: Offset the minimum production finish date (I): To do so, ERP LN takes into account the queue start date of the next operation (G) of operation 10. From there, ERP LN offsets the production time of one transfer batch quantity (the last one that rolls out of operation 10) for operation 20 backward. This results in the minimum production finish date. Check if correction is required (II): Numeral II shows that ERP LN must perform a correctional step, because the wait start date (E) of operation 20 (not corrected) falls before the minimum production finish date found in the previous step. It is obvious that the wait start date must coincide with the production finish date, Postpone operation 20 (III): The result of step 2 was affirmative, which means that ERP LN must postpone operation 20 to let the wait start date of operation 20 coincide with the production finish date. Subsequently, ERP LN offsets the lead-time elements of operation 20 backward to find the start date and time of operation 20. Backward planing with transfer batch quantity Figure 1-3
QT | queue time
ST | setup time
RT | run time
WT | wait time
MT | move time
A | queue start date
B | setup + run start date
C | setup + run restart date
D | first transfer batch finished
E | wait start date
F | move start date
G | queue start date (next operation)
H | setup + run start date (next operation)
Figure 1-3 is a graphical reproduction of a backward planning situation in which you defined a product routing consisting of operation 10 and operation 20. For operation 10, you defined a transfer batch quantity. In a backward planning situation, ERP LN offsets in the opposite direction: the end point of the production activity is known, and ERP LN must calculate when it must start, which means that you must read Figure 1-3 from the bottom to the top. Therefore, starting from the end time of operation 20, ERP LN offsets all lead times of operations 20 and 10 until the start time of operation 10. Figure 1-2 shows that planning operation 10 this way (operation 10 not corrected) can lead to an unrealistic planning situation: in this example, operation 10 would end after operation 20 is finished. To avoid such an unrealistic planning situation, ERP LN performs the following steps: Offset the maximum allowed finish date of the preceding operation (I): to do so, ERP LN offsets the production time of one transfer batch quantity (the last one of operation 20) backward from the wait start date (E) of operation 20. This results in the maximum allowed finish date for operation 10. This is the time point on which the move time of operation 10 must end to be able to produce the last transfer batch quantity on operation 20. Offset the calculated finish date of the preceding operation (II): to do so, ERP LN first offset the move time and the wait time of operation 10 backward from the queue start date of operation 20. Next, from the time point where the first transfer batch quantity is planned to roll out of operation 10 (D), ERP LN offsets the production time of the total order quantity minus one transfer batch quantity, plus the wait time and the move time, forward. This results in the calculated finish date of operation 10. The looped tail of the arrow shows the procedure of step 2. Check if correction is required (III): ERP LN compares the maximum allowed finish date found in Step 1 with the calculated finish date found in Step 2. If the calculated finish date falls after the maximum allowed finish date, ERP LN must perform a correctional step on the planning of operation 10. Advance the preceding operation (IV): if the result of Step 3 is affirmative, ERP LN advances operation 10 to an earlier time to realign the operation with operation 20 to make sure that the end of the move time of operation 10 (G) coincides with the maximum allowed finish date found in Step 1. Note The solution described in the previous section implies a simplification of reality, in which ERP LN plans the total lead time of the production order in a consistent way. In practice, however, the short operation could start directy when the first batch arrives, and then wait a short time to be able to continue with processing the following batch. However, ERP LN does not support this level of detail in the planning. Related topics Lead times in Manufacturing To calculate production times of operations To calculate remaining production time |