The forecast is designed to be the controlling factor for a product when it is used. There are rules in the Forecast Setup that the user can use to establish the maximum increase or decrease for the product by how far out (how many months) the order is. The Forecast module will reduce the requirement to MRP as a forecast is consumed by ships, but will not increase the requirements to MRP beyond the forecast guidelines. It will, however, provide a warning to users that their Sales Order Demand exceeds the forecast (when there is one, and the item is a forecast item on the Sales Order) and refer to a report generated whenever the forecast is regenerated or run by MRP. It is the users responsibility to either adjust the forecast, or adjust the Sales Order accordingly. If the user really does want the extra product over and above the forecast, they can add a line to the sales order that is NOT a forecasted item, and then both the forecast and the sales order should drive demand.
The Forecast checkbox is defaulted as True within the SO Module whether or not there actually is a forecast. By doing this, we minimize the possibility of the MRP double ordering parts for the SO. If there is no forecast for the product, MRP will look at the SO as normal and create the demands. As soon as a Forecast is created for that product (regardless if Forecast Detail is blank) the system will then consider the Forecast information over the SO schedule for MRP. The users can un-check the Frcst check box within the SO/WO for that item if desired. The user will then receive a warning message that the orders exceed the forecast and to read the report to verify that’s what the user wants. (This is done so that the customer doesn’t try to sneak in last minute upswings that exceed the forecast).
Note: The programmers have confirmed that we do have a bit of a disconnect. The Forecast setup has 24 "Future Periods", and the Forecast Module "Detail" tab is setup for 26 weeks. At the time it was originally designed it was not seen as a need to go out that far within the Forecast module itself. We do recognize that this needs to be addressed by making changes to the Forecast module to add another page to extend the weeks out further.
The 2 principal methods ( Firm Planned WO being the only other) of driving demand in the MRP system are:
- Forecasts
- Sales Orders ( only those flagged as non-consuming )
It is important to draw the distinction between the two kinds of Sales Order items that exist in Manex.
- Forecast-Consuming Sales Orders ( these do not drive demand unless no active forecast exists for the item )
- Non-consuming Sales Orders ( drives demand in addition to the Forecast if it exists )
The default during Sales Order Entry is that the Flag is set to consuming. If the sales order has an active forecast, the Sales Order will not drive demand – shipments against it will reduce Forecast by the same amount. If there is no active forecast, it will behave exactly the same way as a non-consuming SO. If an item is dropped from the Forecast (revision change or otherwise), what do we do with the consuming Sales Order? Should the system prompt if there are Sales Orders with consuming set to “yes”, yet there is no Sales Order.
Forecasts
Forecasts can be loaded for up to 24 weeks for any assembly/rev into the Manex Forecast Module. Forecasts are uploaded from an XL template. Forecast module buckets the loaded demand into weeks.
The calculation of “net demand to MRP” is as follows:
Forecast Qty-shipments ( consuming sales orders only)
In other words as we ship against the Forecast the net demand decreases by that amount.
As Consuming Sales Orders are created they may have schedule ship dates that do not align with the Forecast. For example , customer may provide Sales Orders with quantities that are due on a date before the Forecast due date. Since we are driving material to the Forecast date, this might create a condition where we cannot meet the date. The Forecast module generates a report where you can view the alignment of the Sales Orders to Forecast. This is an important report to review with the customer.
In the event that the total consuming Sales Order qty exceeds the entire forecast ( you can see in the afore mentioned report) you should advise the customer that we will not be driving demand for the excess. They must either amend the forecast or clearly indicate. in the PO ( or through some other dependable means ) that the PO is in addition to the Forecast.
Each new Forecast is compared to the previous to look for differences. The following analysis is performed by the system:
| Review of results |
Probable reason |
Analyst Action |
| Are there any new items? |
New parts being driven |
|
| Have any revisions changed? |
This could be the reason for item 1. |
Analyst must copy the forecast of the old rev to the new rev so that we do not lose the history and are able to apply the violation tolerances appropriately. Then the new forecast is loaded at the new revision.
|
| Have some items been dropped from the Forecast? |
Revision change or demand has completely disappeared |
Analyst must note that there is a setup option by customer which will inactivate any existing Forecast that is not present in the new forecast. In other words, only items in the most current forecast are driven. There is potential excess from such a change and must be reviewed carefully. |
| What are the potential changes in “net demand to MRP” in demand as a result of the new forecast? |
|
|
|
Have any of the quantities changed where they violate the allowed flexibility?
A typical Customer Forecast flexibility may be as shown in the next table |
|
Analyst should review. If it is not clear why there is a violation ( last forecast same as current) then run a waterfall report for the part in question. The violation may have happened in previous weeks and the forecast was forced.. |
| 0 to 30 days |
No Change Allowed |
| 31 to 60 |
25% Change |
| 61 to 90 |
50% Change |
| 91 Plus |
Unlimited flexibilty |
The responsibility of the Forecast analyst or PM is to review the reports and seek appropriate resolution from the customer before the end of the week.
| 
