You use this program to schedule existing and suggested jobs according to the available capacity (i.e. to apply finite capacity). Job start and delivery dates are automatically re-calculated and operations within each job are re-scheduled.
The program advises on demands that cannot be satisfied. Manipulation of the demand chain, followed by further forward scheduling runs may be necessary to achieve a viable production plan.
A reason for using the Forward Finite Scheduling is that the Requirements Calculation program assumes infinite capacity and does not, therefore, schedule jobs according to the actual available capacity in each work center. Single level forward finite scheduling loads operations in accordance with the availability of free capacity thus calculating elapsed times and queue times (the move times remain fixed) from a designated start date to establish a delivery date.
![[Note]](images/note.png)
|
|
|
Forward Finite Scheduling in MRP uses the snapshot data created/copied by the Requirements Calculation (Requirements Calculation). The Calendar and the Capacity profile copied into the snapshot at Requirements Calculation time are applied. |
|
- Toolbar and menu
- Information
- Report
- Scheduling Phases
- Scheduling an Operation
- Available Capacity and Usage
- Notes and warnings
| Field | Description |
|---|---|
| Run Scheduler | Select this to run the scheduler. |
| Select this to print the report. | |
| Save Form Values | This option is only enabled in Design mode (Automation Design). Your selections are saved and applied when the
program is run in automated mode. Form values and defaults are applied at operator level. They are not saved at role or group level. |
| Field | Description |
|---|---|
| Processing options | |
| Apply overtime percentages |
Select this to apply overtime percentages (held against the work centers) to the total capacity available on any given day (work center capacity file). For example: If a work center has a daily capacity of 8 hours and an overtime percentage of 25%, then the capacity available will be calculated as 10 hours (assuming 100% utilization). |
| Requirements calculation date | This indicates the date on which the Requirements Calculation program was used to create the snapshot. |
| After processing completed |
These options are displayed within programs that can be automated. They enable you to indicate the action you want to perform once processing is complete (see Automation Design). |
This pane displays the results of the processing function you selected once processing is complete (unless you selected the option to close the application from the After processing completed section).
Refer to Errors for explanations of some of the errors that could be displayed in the Description column.
The following are some of the errors/warnings listed on the Forward Finite Scheduling error report:
| Error | Comment |
|---|---|
| Queue limit exceeded | Check the setup option: Finite schedule generated queue time for finite scheduling (Requirements Planning Setup). This option indicates the maximum queue time allowed when calculating forward finite capacity, setting a limit on the insertion of operations into the capacity profile for each work centre. |
| Date calculation method | Using calculated dates (specifically delivery dates) will most likely solve the errors that Finite Scheduling is encountering. |
| Insufficient elapsed time booked | This means that these jobs most probably have manually entered start and delivery dates. In theory, it means that capacity is still required, but there is no more elapsed time available. |
| Elapsed time > working days available | This means you require more time to complete the job than is available (according to the due dates). Move out the delivery/due dates or schedule overtime. |
| Cannot generate queue for started op |
This is caused by the forward finite scheduler trying to load a started operation onto the work center, which does not fit. If the operation was not started then it tries to move the operation forward by adding queue time, however because it has started you cannot add queue time. This can be caused by not posting time in a sequenced manner (i.e. not posting to operations 1, 2, 3, 4, etc., but randomly to operations 3, 2, 4, 1, etc., for example). What is happening is that the program is finite scheduling the un-started operations, but then coming across the started operation and trying to load it. This message is also displayed when an operation has a quantity completed against it, irrespective of whether a quantity outstanding still exists against the operation. The operation is deemed to have been started so the scheduler cannot load the operation. |
The Forward Finite Scheduling program goes through the following phases:
- Initial checks
- Sequencing of jobs
- Scheduling of jobs
- Reloading of jobs (if errors occur)
This phase of the program checks that the required data is available. The program checks that:
- The setup option: Requirements Planning Load levelling required is selected (Requirements Planning Setup).
- There is a valid snapshot file (i.e. the Requirements Calculation was run).
- The live data has not been updated from the snapshot.
If these prerequisites are not met, the program will not run. If met, it moves to the next phase.
This phase of the program reads through the pegging file extracting jobs (existing and suggested) and, providing the demand date is before the year 2040, adds a record to a temporary file which has the following primary sequence:
- Started non-manual jobs (i.e. date method not Manually entered dates).
- Manually dated jobs.
- Non started operations for started jobs
- Confirmed jobs
- Unconfirmed jobs
- Suggested jobs.
Within the primary sequence, the following sequence applies:
- Jobs will be loaded either in priority or start date sequence depending on what has been selected against the Requirements Planning Setup option: Assign higher priority to start date or job priority.
- Delivery date.
- Job number.
The pegging record for this job is then deleted and the supply field in the corresponding demand record is reduced by the quantity to manufacture.
During this phase, any pegging records found for material allocations are also removed and the demand field in the corresponding demand record is reduced by the quantity required.
If no job records are found on the pegging file, a warning message is displayed.
Once a job is completely loaded (whether successfully or with an error), the pegging for the job and its allocations are re-created. The supply field (finished part) and demand fields (material allocations) of the corresponding demand records are also updated.
The dynamic capacity profile file in the snapshot directory is deleted.
Using the temporary file (created during the previous phase), jobs are re-scheduled in the following sequence:
-
Started/completed operations for jobs which are not manually dated.
When loading started internal operations, the following rules apply:
- No capacity records are written for capacity issued.
- Any outstanding capacity is loaded in forward finite mode with the starting date of loading being the date on which the Requirements Calculation was run.
- If this capacity cannot be loaded with the Requirements calculation date being the start without generating queue, then the program writes out an error and reloads the job accordingly.
- Once any outstanding capacity is loaded, then, starting at the last working day PRIOR to the calculation date, the program calculates the elapsed time based for the capacity already issued. (The assumption is that any capacity issued was issued prior to the calculation date). If the capacity issued is greater than that planned for the operation, the program will assume that it is complete.
- The elapsed time calculated for outstanding capacity and capacity issued are then added together.
- If the operation is not flagged as having a dynamic elapsed time and the new calculated elapsed time is greater than that held on file, an error is given and the job is reloaded accordingly. If, on the other hand the calculated elapsed time is less than that on file a warning will be printed. The calculated start/end dates will be based on the elapsed time on file.
Example of how a started internal operation is loaded.
Calculation date 25/11/97 Capacity required 40 hours Capacity issued 15 hours Capacity per day 8 hours Date Capacity 23/11/97 7 24/11/97 8 25/11/97 8 26/11/97 8 27/11/97 8 28/11/97 1 Calculated start date 23/11/97 Calculated end date 28/11/97 Elapsed time 6 days
If the calculated start date for any started/completed operation is prior to the planned job start date on file then the operation's start date becomes the job start date.
-
Manual (Mandatory) dated jobs.
Jobs using Manually entered dates are loaded in the following manner:
- The program tries to load the operations within their start/end dates according to the gross capacity available for the day(s).
- If there is insufficient capacity available using this method, it divides the capacity required by the number of days elapsed time on file and updates the capacity profile irrespective of the overloads caused.
- If there is more than enough elapsed time allocated to the operation, a warning is printed.
- All operations for the job are loaded in the same fashion. It does not check whether the operation has started or is complete.
No changes are made to the planned dates on either the job header or its respective operations. The elapsed time etc., also remain the same (i.e. only capacity profiles are affected).
-
Remaining operations for started jobs which are not manually dated.
The calculation of the total number of days required to complete all operations (i.e. queue time, elapsed time, start time, complete time and move time) is affected by your selection at the setup option: Operation to end earlier than prior (Work in Progress Setup).
Once all started/completed operations and all manually dated jobs have been loaded, the started jobs (already partially loaded) are re-checked, for all the operations not previously loaded (non started operations). These are loaded as follows:
-
First operation (started)
If the first operation has already been scheduled (it was found to be either started or completed) and the job start date does not equal the calculated operation start date, queue time is generated from the job start date up to the operation start date. If this queue time exceeds the limit set up in Requirements Planning Setup options an error is issued and the job is reloaded. The start date on the job may differ from the start date of the first operation if other started operations within the job have caused the job start to be moved back in time.
-
First operation (not started)
If the first operation has not been started, queue time is generated from the job start date up to the last working day prior to the calculation date. Again, if the queue time is exceeded, an error is issued and the job is reloaded. The operation is then loaded in the same manner as all other non started operations, adding to the established queue time if necessary. This may occur if no sequence checking is required for the job.
-
Subsequent started/completed operations
These operations (having already been loaded) are not changed in any way but their movement time is added to the operation's end date so that, if the following operation is not started, it has a date from which to attempt loading.
-
Non-started operation following a started operation
The date calculated is compared to the planned start of this operation. If it is later, queue time is generated between the two dates. The operation is then scheduled as a normal operation (refer to Scheduling an Operation).
-
Non-started operation following a non-started operation.
These are loaded in the normal way (refer to Scheduling an Operation).
The following rules apply when scheduling operations:
-
Started subcontract operations
The program compares the planned start date against the MRP calculation date. The operation is then loaded using the method Delivery date to be calculated (forward infinite), starting at the lower of the two dates.
-
Completed (internal and subcontract) operations
The program compares the actual finish date against the MRP calculation date. If the actual finish date is later, then the program assumes that the operation was actually finished on the last working day prior to the calculation date.
The start date is calculated using the method Start date to be calculated (Backward infinite) with the end date being the result of the above.
-
-
4. Scheduling non-started jobs
All those jobs and suggested jobs which have not already been processed are now loaded according to their sequence in the temporary file.
If an error is encountered while trying to load a job, the program will remove all capacity loaded up to the time of error. It will then restore the loaded operations to their initial state (to correct any capacity, queue time etc., changes).
Once this is done the program will reload the job using the method Start date to be calculated (Backward infinite) from 31 December 2045.
-
Subcontract operation
Although true queue time cannot be applied to a subcontract operation, if the first operation is subcontract and the job start date is prior to the calculation date, the program will treat the difference in working days (based on the company calendar) as queue time and will check that they do not exceed the queue time limit set up in Requirements Planning Setup options.
If the limit is exceeded then an error is issued and the job loaded accordingly. If the job start date is not in the past, it is assumed to be the start date of the operation.
Once the start date is established the operation is scheduled forward infinite i.e using the date calculation method Delivery date to be calculated. This will calculate the end date for the operation and add the movement time to establish the start date for the next operation.
-
Internal operation
As with a subcontract operation, if the operation start date is prior to the calculation date, the program will treat the difference in working days (based on the work center calendar) as queue time and this will be checked against the queue time limit set up in Requirements Planning Setup options.
Operation one is presented to the capacity profile (the queue date and start date for the operation equal the job start date). The program then proceeds through the following loop trying to load the capacity required for the operation:
- If the date is prior to the calculation date, and is classed as a working day, it is assumed that any available capacity on that day is in use and queue days will be generated until the day prior to the calculation date is reached or the Requirements Planning queue limit is exceeded. If the date is not in the past and it is a working day, then the program checks to see what the net capacity available for the day is.
- If the net capacity available is zero then one day is added to the queue and the start date is incremented to the next working day. This process is continued until some capacity becomes available. If the queue limit is exceeded before capacity becomes available an error is issued and the job is loaded accordingly.
- Once a start date has been established, the program checks whether the subsequent days have sufficient capacity to sustain the maximum capacity required for each day until the operation's capacity required is exhausted. Note that the last day may require less capacity than the maximum required per day.
- Should any working day fail to provide sufficient capacity before the operation is loaded, the queue time is incremented and, if it is still within the Requirements planning queue limit, a new start date is generated from which the entire cycle is re-implemented.
-
If, however, the queue limit has been exceeded, the operation is checked for the number of productive units to use. Should the operation only allow one productive unit, an error is issued and the job is reloaded. If more than one productive unit is specified against the operation, this number is decremented by one and the loading process re-started at the start date established when the first available capacity was found.
This process of reducing the number of productive units each time the Requirements planning queue limit is reached is continued until either the operation loads successfully or the number of productive units cannot be reduced any further (i.e: the operation failed to load using one productive unit) in which case the job is reloaded.
- When an operation has been successfully loaded, if the operation has a dynamically calculated elapsed time, it will be updated with the new generated elapsed time. However, if the elapsed time is a manual one (this includes all estimate operations), the elapsed time against the operation is compared to the new generated elapsed time.
- If the new elapsed time exceeds the manual elapsed time, an error is issued and the job is reloaded. If the new elapsed time is less than the manual elapsed time, a warning is issued and the manual elapsed time is retained and used to calculate the queue/start date of the next operation.
- Once the end date is established, the move time is added to calculate the start/queue date for the next operation. If, however, the next operation is started/completed then it uses the dates already calculated.
This loop is repeated until the last operation has been processed. Once the job has been loaded the program recreates the pegging records and updates the demand file according to the new dates.
Capacity available on a day is calculated as follows: A x B x C Where: A = Capacity on a day (work center calendar) B = Overtime % C = Utilisation %
|
|
|
|
Overtime % is only available if the work center setup option: Use overtime is selected. |
|
Daily operation capacity required (except first & last days) is calculated as follows: (A/B) x C x D x E Where: A = Capacity on a day (work center calendar) B = Number of productive units on a day (work center calendar) C = Number of productive units on the operation D = Utilisation % E = Overtime %
The general rules applied when allocating an operation are as follows:
- A queue time cannot be calculated which exceeds the limit specified in the Requirements Planning Setup option Maximum generated queue time.
- Except on the first or last days of an operation, the full capacity of the designated number of productive units to be used on the operation must be loaded.
- The days on which capacity is loaded for an operation must be contiguous working days.
If the number of productive units on the operation exceeds the number of productive units on a given day, the operation's number of productive units is taken to be equal to the number of productive units on a day.
If the Elapsed Time on the operation record is set as Fixed, then that operation's dates are calculated as if using the date method Delivery date to be calculated.
If updating a job, any operations prior to the highest operation to which time has been posted will be processed as having the date method Delivery date to be calculated.
No subcontract operations are processed using forward finite scheduling and are assumed to have the date method Delivery date to be calculated.
Forward finite scheduling has only a single level capability, i.e. it is not able to adjust any requirement that the job being loaded may be supplying.
-
You cannot run this program if the Requirements planning load levelling option is disabled (Requirements Planning Setup) or you do not have a valid snapshot file (i.e. you have not run the Requirements Calculation program).
Electronic Signatures provide security access, transaction logging and event triggering. This enables you to increase control over your system changes.
Access to the following eSignature transactions within this program can be restricted at Operator, Group, Role or Company level. You configure this using the eSignature Setup program.
| eSignature Transaction | Description |
|---|---|
| MRP Forward finite scheduling |
Controls access to the Run Scheduler function in the Forward Finite Scheduling program. |