Business contracts often include allowable schedule variances with potential penalties for the customer if violated. The tolerance check is an optional step in the flow but is a key feature of the application. This check provides a way for the supplier to recognize, and, if necessary, present actual facts and figures associated with any schedule variance violations.
The two main tolerance calculations are cumulative schedule tolerance and bucketed schedule tolerance call-off.
Regardless of the tolerance calculation method you choose, it is possible to make different comparisons. There are four alternatives: compare plan to plan, compare call-off to plan, compare call-off to call-off, or compare cumulative call-offs to plan. These alternatives can be combined and used according to the currently entered schedules.
Comparing cumulative call-offs to plan is a different means of gathering the schedule data for comparison by assembling the net effect of multiple overlapping call-offs. The result of the combined schedule can be used by both the cumulative and the bucketed tolerance check method.
When you use the cumulative schedule tolerance check, the basis for comparison across the entire horizon is a single tolerance percentage (one for schedule increases and one for decreases) rather than a tolerance template. Users can compare common date ranges in the following schedules by using one of these checks: Plan to Plan, Call-off to Call-off, Call-off to Plan, and Cumulative Call-offs to Plan. In all cases except the Cumulative Call-offs to Plan, the check evaluates a specific (presumably the latest) schedule against the most recent previous schedule. The Cumulative Call-offs to Plan check, however, evaluates several call-offs against the last plan.
Retrieve all Schedule Lines meeting the input parameters for which tolerance checks are to be performed.
For each Schedule Line, take the releases (where demand information is not Information Only) and convert them to daily quantities. Daily quantities are calculated by spreading the numbers across the number of working days between schedule dates. For the last record in the schedule, the system uses the end date of the schedule header.
Example:
Date | Quantity | Period Covered |
199X-10-06 09:00 | 60 | Sub-day |
199X-10-06 12:00 | 40 | Sub-day |
199X-10-07 | 120 | Day |
199X-10-08 | 130 | Day |
199X-10-09 | 110 | Day |
199X-10-10 | 100 | Day |
199X-10-13 | 500 | Week |
199X-10-20 | 600 | Week |
199X-10-27 | 650 | Week |
199X-11-01 | 2200 | Month |
199X-12-01 | 2400 | Month |
If multiple records exist for the same date, consolidate them into a single value.
Date | Quantity | Period Covered |
199X-10-06 | 100 | Day |
199X-10-07 | 120 | Day |
199X-10-08 | 130 | Day |
199X-10-09 | 110 | Day |
199X-10-10 | 100 | Day |
199X-10-13 | 500 | Week |
199X-10-20 | 600 | Week |
199X-10-27 | 650 | Week |
199X-11-01 | 2200 | Month |
199X-12-01 | 2400 | Month |
Now the records are 'spread' into daily requirements. Starting with the first date, retrieve the next date in the schedule. Calculate how many working days this covers, based on the regular system calendar. If the next date on the schedule is one day away and is also a working day, then no spreading logic is required. This applies to the first five buckets in the example. When record 6 is compared to record 7, the number of elapsed days between records is seven, though only five are working days. Thus, five equally sized daily buckets are created. (Note: Some rounding might be required here.) This principle is applied to all the buckets, except the last; in the last bucket, the bucket size is created by using the first date after the end date of the previous release record as the start date, and the end date of the schedule header as the final date. Result now appear as follows:
Date | Quantity | Period Covered |
199X-10-06 | 100 | Day |
199X-10-07 | 120 | Day |
199X-10-08 | 130 | Day |
199X-10-09 | 110 | Day |
199X-10-10 | 100 | Day |
199X-10-13 | 100 | Day |
199X-10-14 | 100 | Day |
199X-10-15 | 100 | Day |
199X-10-16 | 100 | Day |
199X-10-17 | 100 | Day |
199X-10-20 | 120 | Day |
199X-10-21 | 120 | Day |
199X-10-22 | 120 | Day |
199X-10-23 | 120 | Day |
199X-10-24 | 120 | Day |
199X-10-27 | 130 | Day |
199X-10-28 | 130 | Day |
199X-10-29 | 130 | Day |
199X-10-30 | 130 | Day |
199X-10-31 | 130 | Day |
199X-11-01 | 110 | Day |
199X-11-02 | 110 | Day |
... | ... | ... for each day in the month |
199X-12-01 | 120 | Day |
199X-12-02 | 120 | Day |
... | ... | ... for each day in the month |
The cumulative information and cumulative variances are now recorded. For this example, let us assume a simplified situation with two call-off schedules already bucketed in daily periods. Each week, we receive a new call-off covering two weeks' worth of information. Thus, there is one week of common schedule data that can be compared on this cumulative schedule basis. Assuming a cumulative schedule tolerance of 5%, the following schedule would result in an Out of Tolerance situation:
Date | Call-Off No1 | Call-off No 2 | Call-off No 1 Cumulative | Call-off No 2 Cumulative | Cumulative Variance (%) |
199X-10-13 | 90 | ||||
199X-10-14 | 90 | ||||
199X-10-15 | 95 | ||||
199X-10-16 | 95 | ||||
199X-10-17 | 95 | ||||
199X-10-20 | 100 | 100 | 100 | 100 | 0 |
199X-10-21 | 100 | 107 | 200 | 207 | 3.5 |
199X-10-22 | 100 | 108 | 300 | 315 | 5 |
199X-10-23 | 100 | 105 | 400 | 420 | 5 |
199X-10-24 | 100 | 110 | 500 | 530 | 6 Out of Tolerance |
199X-10-27 | 110 | ||||
199X-10-28 | 110 | ||||
199X-10-29 | 120 | ||||
199X-10-30 | 120 | ||||
199X-10-31 | 125 |
Note that individual daily deliveries can vary by greater than the tolerance as long as the cumulative effect does not exceed the tolerance percentage.
The spreading logic for the previous plan is identical to the spreading logic performed on the current plan. Also note that only overlapping date information is useful for tolerance checking - the date limits of each schedule are the limits of the comparison.
The user scenario and input parameters for the bucketed schedule tolerance check are identical to the cumulative schedule tolerance check. The difference is in the tolerance algorithm and the data source of the tolerance percentage. Just as with the previous check, the comparison is run against the current schedule, meeting the input criteria for whatever comparisons are desired by the user (e.g. Plan-to-Plan, Call-off-to-Plan). The major difference between this and the previous logic is that a tolerance template is used as a means of changing the acceptable tolerance over the schedule horizon, a different tolerance per 'bucket.'
The initial steps in the bucketed tolerance check are identical to those of the cumulative schedule check. The release quantities expressed on the compared schedules are first spread into a daily format. The daily format is then used as the basis for accumulating the requirements into buckets. The daily format is important, since the bucket definitions can divide a given release's date range.
Once the daily quantities are defined, the correct template definition is retrieved for the customer agreement line record.
Retrieve the start date from the first record in the latest schedule.
Using the definitions from the template, summarize the daily quantities from the releases into the bucketed quantities. For
example, bucket 1 might be for five days, so you would accumulate all the schedule quantities' numbers from the schedule
valid-from date to the valid-from date plus 4 days.
An example of the current schedule with quantities bucketed into template format:
Bucket | Length | Period | Quantity | No Days | Tolerance (%) |
1 | 5 Days | Firm | 560 | 5 | 2 |
2 | 10 Days | Fabrication | 1100 | 10 | 5 |
3 | 20 Days | Material | 2300 | 20 | 10 |
4 | 40 Days | Forecast | 2950 | 25 | 20 |
Although bucket 4 is 40 days long, the schedule has values converting only 25 of those days. For a valid comparison, the previous schedules are also prorated, adjusted to the smaller numbers where the number of days is different for any bucket.
Let us assume that this schedule must be compared with two previous schedules (i.e., one a call-off, one a plan):
Bucket | Length | Period | Quantity | No Days |
1 | 5 Days | Firm | 600 | 5 |
2 | 10 Days | Fabrication | 300 | 5 |
3 | 20 Days | Material | 0 | No data |
4 | 40 Days | Forecast | 0 | No data |
Bucket | Length | Period | Quantity | No Days |
1 | 5 Days | Firm | 400 | 5 |
2 | 10 Days | Fabrication | 1200 | 10 |
3 | 20 Days | Material | 2000 | 20 |
4 | 40 Days | Forecast | 2200 | 20 |
To successfully compare to the above schedules, the current schedule quantities would have to be adjusted as follows:
Bucket | Length | Period | Quantity | No Days | Comments |
1 | 5 Days | Firm | 560 | 5 | |
2 | 10 Days | Fabrication | 550 | 5 | Prorated to 5 days |
3 | 20 Days | Material | Prorated to 0 days | ||
4 | 40 Days | Forecast | Prorated to 0 days |
Bucket | Length | Period | Quantity | No Days | Comments |
1 | 5 Days | Firm | 560 | 5 | |
2 | 10 Days | Fabrication | 1100 | 5 | |
3 | 20 Days | Material | 2300 | 20 | |
4 | 40 Days | Forecast | 2360 | 20 | Prorated to 20 days |
Having adjusted the figures to a comparable form, the tolerances by bucket can now be calculated:
Bucket | Length | Period | Current | Previous | No Days | Variance (%) |
1 | 5 Days | Firm | 560 | 600 | 5 | - 6.7 Out of Tolerance |
2 | 10 Days | Fabrication | 650 | 300 | 5 | +116.7 Out of Tolerance |
3 | 20 Days | Material | No data | |||
4 | 40 Days | Forecast | No data |
Bucket | Length | Period | Current | Previous | No Days | Variance (%) |
1 | 5 Days | Firm | 560 | 400 | 5 | + 40 Out of Tolerance |
2 | 10 Days | Fabrication | 1100 | 1200 | 5 | - 8.3 Out of Tolerance |
3 | 20 Days | Material | 2300 | 2000 | 20 | + 15 |
4 | 40 Days | Forecast | 2360 | 2200 | 20 | + 7.3 |
The result of the comparison is that both comparisons fail the tolerance check and cannot be automatically approved.
The cumulative call-off check is a different way of gathering the schedule data for comparison and can then be used by both the cumulative and the bucketed tolerance check method.
In this case, the actual tolerance check is performed identically to one of the two previously described algorithms. Cumulative call-offs is a way of defining the schedule data for comparison by combining the net effect of several overlapping call-offs. This is useful for cases where the user receives multiple call-off schedules between plans. For example, if a plan was delivered weekly but call-offs were delivered every day, there would be five call-offs delivered against a previous plan. This type of comparison of call-offs to plans, through either a cumulative or bucketed tolerance check algorithm, can be used.
In the following example, the situation is just as described above - each week, the user receives a plan covering two weeks of schedule information. A call-off is sent each day, covering the next two days' worth of shipment information. Each day, the overlapping part of the previous call-off is overridden by the next.
The assumption for this process is that any time a release quantity is specified for the same date as expressed in a previous schedule, it overrides that release. If there is no overlap of schedule dates, then the quantity remains intact.
Date | Latest Plan | Previous Call-off No 1 | Previous Call-off No 2 | Latest Call-off No 3 |
Cumulative Call-off |
199X-10-01 | 20 | 21 | 21 | ||
199X-10-02 | 20 | 21 | 22 | 22 | |
199X-10-03 | 20 | 22 | 23 | 23 | |
199X-10-04 | 20 | 24 | 24 | ||
199X-10-05 | 20 | ||||
199X-10-08 | 25 | ||||
199X-10-09 | 25 | ||||
199X-10-10 | 25 | ||||
199X-10-11 | 25 | ||||
199X-10-12 | 25 |
As each call-off arrives, it overrides the previous call-off covering the schedule dates. Thus the 'cumulative' call-off schedule is built. Having assembled this data, one of the standard tolerance check algorithms can be run against this composite schedule, either cumulative or bucketed, as described above. Notice that in all call-off to call-off comparisons, tolerance checking would find the numbers to be within 5% of the previous. However, viewed as a composite, the tolerance varies substantially from the previous plan numbers, finally reaching a 20% variance.
In this example, the call-off quantities arrive in daily quantities, though this is not necessarily the case. Just as with other examples, the call-off quantities could cover multiple days and thus a daily spreading algorithm would be performed for each schedule involved in which date information overlaps. The same results could then be used for a bucketed tolerance comparison as well. Once a new plan arrives, the cumulative call-off is no longer as significant, and the call-offs against the new plan begin to accumulate for the next cycle.
An important note: The tolerance check process is executed against Call-off No 3. (Input criteria for tolerance-check picks up this schedule). The values for the previous two call-offs (any call-off found between the latest call-off and the latest plan) are assembled into a composite view and compared to the plan. However, if values are out of tolerance, the schedule considered to cause the 'Out of Tolerance' condition is Call-off No 3. Thus, the comparison is associated with Call-off No 3 - this is the schedule that would be questioned to view tolerance check results for out-of-tolerance schedules.