|Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search|
|Forecast/Planning Models Index | Supporting Documentation | Downloads | FAQs ||
General Information and Considerations
Forecast/Planning Models are better understood in the context of replenishment. The Replenishment Scenario Matrix shows how Forecast/Planning and Order models interact to form Replenishment models.
General Notes and Recommendations Applying to all Models and Scenarios
These are recommendations that apply to many models and their transactions or messages. The recommendations have not all been updated (yet) to include cross-references to RosettaNet and OAG, but the general principles apply.
Forecast/Planning Models: General Information and Considerations, including:
A forecast is an estimate of future demand. Generally, trading partners establish agreements regarding "frozen" zones, whereby it is agreed that demand will be frozen and not change; usually the frozen zone is established to be at lead time. Lead time may be negotiated to be anything from true manufacturing lead time to ordering lead time. In the processes described in this document, it is assumed that agreements are made for sellers to plan to forecast, and the agreements include clauses about liability on the buyers part for raw materials, labor, overhead, and schedule flexibility (upside or downside in demand). In this way, order lead time can be set to a minimal value, allowing releases against the forecast to be made virtually at zero lead time or "just-in-time.
Planning Forecast - Used in Customer-Managed Inventory Replenishment processes. A forecast file containing only planned requirements (no firm requirements), net of inventory. There are no replenishment triggers included with the data. The planning forecasts represents buyer's planned future orders. Schedules for near-term planned requirements are usually expressed as discrete quantities with planned delivery dates or planned shipment dates. Longer-term requirements may be expressed as bucketed quantities (weekly, monthly, quarterly, etc.); either a start and end date for the period is specified, or, if a single date is specified, it represents the "begin date" of the forecast period. When a forecasted schedule becomes firm, it is deleted from the forecast and a replenishment trigger is issued separately, either as discrete, standalone purchase orders, or a discrete release against a Blanket Purchase Order. The Planning Forecast is also called "Simple Forecast" or "Order Forecast".
Material Release Schedule (a/k/a "Embedded Release Forecast")
Used in Customer-Managed Inventory Replenishment processes. A forecast file containing both planned requirements and replenishment triggers for firm requirements. The replenishment triggers represent releases against a Blanket Purchase Order. However, no separate replenishment trigger is sent. The seller detects the replenishment triggers contained inside the Material Release Schedule, and processes them against the designated Blanket Purchase Order . The forecast schedules are net of inventory. All firm schedules are expressed as discrete quantities with firm requested delivery dates or firm requested shipment dates. Schedules for near-term planned requirements are usually expressed as discrete quantities with planned delivery dates or planned shipment dates. Longer-term requirements may be expressed as bucketed quantities (weekly, monthly, quarterly, etc.); either a start and end date for the period is specified, or, if a single date is specified, it represents the "begin date" of the forecast period.
Planned Consumption Schedule (a/k/a
"SMI Forecast" or "Threshold Forecast")
Used for: Supplier-Managed Inventory (a/k/a "Vendor-Managed Inventory")
Used inSupplier-Managed Inventory Replenishment processes. A forecast file containing the buyer's gross planned requirements. The Consumption Schedule represents what the buyer plans to use, sell or transfer out on the specified date or in the specified period. Additional information is included that allow the supplier to perform the requirements netting and determine when the buyer's inventory should be replenished: buyer's available inventory, receipt and/or in-transit data, and the buyer's inventory thresholds for minimum and maximum on-hand quantities. Schedules for near-term planned consumption are usually expressed as discrete quantities and the date when the quantity will be used, sold or transferred. Longer-term requirements may be expressed as bucketed quantities (weekly, monthly, quarterly, etc.); either a start and end date for the period is specified, or, if a single date is specified, it represents the "begin date" of the forecast period.
Purchase Order (PO) - A type of contract between a buyer and a seller. Regardless of what it is called, there is always something that serves the legal function of "purchase order" when a buyer makes a request for goods or services to be provided. When the seller agrees to provide the goods and services, and both parties agree on the price, a binding contract exists between buyer and seller. Note that the delivery dates don't have to be agreed upon in order for a binding contract to exist. /The two major types of orders are Discrete Purchase Orders and Blanket Purchase Orders
Release - An authorization to produce or ship material which has already been ordered.
Release, Discrete - A stand-alone document or message, authorizing the shipment of material against a blanket order.
Release, Embedded - See Material Release Schedule.
Receipt Acknowledgment - a/k/a Functional Acknowledgment, Control Message. When one party (e.g. buyer) sends an electronic message to another party (e.g. seller), the recipient sends back a signal backadvising the sender that the message reached the intended destination, and indicating whether or not the message was syntactically correct and in conformance to the standard identified in the message. The receipt acknowledgment is called a "business signal" by some in order to distinguish it from a business document containing business data. A receipt acknowledgment has no legal authority - it does not address the business contents of the sent document. The origin and destination are usually eBusiness gateways. The signal sent back to the originator generally indicates that the message was received at the recipient's gateway; it does not guarantee that the message made into the recipient's back-end application. The reliability of the interface between the recipient's gateway and recipient's back-end application should be determined as part of the testing and implementation process.
Factors Influencing Choice of Forecast/Planning ProcessThe choice of which Replenishment Scenario to use is the primary factor in deciding which Forecast/Planning model to use. A secondary consideration is whether or not consignment (a/k/a supplier-owned inventory, line side stocking) does or does not need to be supported.
There are other factors involved
in deciding which Forecast/Planning Model to use, and one choice may be not to use any
Forecast Planning Model. This document outlines some business environments and guidelines
for choosing Forecast Planning Models.
The choice of which Forecast/Planning Model to use is a factor in deciding which Order Model to use. Refer to "Implementation Recommendations for Blanket Purchase Order Transactions" for further information.
The core EIDX Replenishment Scenarios are:
Replenishment Scenarios are created by mixing and matching Order and Forecast models. While Order, Forecast, and other models are documented as separate models, there is a close relationship between them. For example, Order Model 2 may be paired with Forecast Model 2 as part of an overall forecast and inventory management business process; Forecast / Planning Model 1 is appropriately paired with Order Model 1. The pairing of some models may be inappropriate. There are several business models identified by EIDX which utilize blanket orders and some type of requirements release (either the buyer or the seller releases requirements). The EIDX Replenishment Models represent the recommended pairings of Order and Forecast models. See Recommendations on Which Replenishment Process to Use and Summary Comparison of Replenishment Methodologies.
Original Equipment Manufacturers (OEMs) may get forecast/planning data from one or more of the following sources:
- Pass-through from customers
- Programs (remote warehouse, JIT, etc.)
- New products
- Materials Requirements Planning (MRP)
- Marketing forecast
Contract Manufacturers (a/k/a Subcontractors) may get forecast/planning data from one or more of the following sources:
- Projects/open orders
- Planned orders
- Pass-through from customers
- Materials Requirements Planning (MRP)
Distributors (a/k/a Value-Added Resellers) may get forecast/planning data from one or more of the following sources:
- Sales representative information
- Point-of-Sale (POS) - sales history, end customers, suppliers
- Cost to stock
- Guide price
- Design Wins
- Minimum and maximum inventory levels
- Lost sales
Uses For Forecast Data:
Releases Against Forecasts
[Some of the following is from the original forecast supporting document. Some of it may belong in the documentation for the replenishment models. But since the outcome of forecast/planning is what and when to replenish, some of this may belong here, since it gives information that will lead to the decision of which replenishment process to use with which forecast/planning process.]
Releases Against Planning Forecasts
The release mechanism (authorization to commit
resources and ship) for traditional Planning Forecasts is the discrete Purchase Order. The
release of the discrete POs (migration of demand status from planned to firm) is
controlled by the buyer. However, unless there are contractual agreements in place
regarding the buyers commitment to the forecast, the release is not legally a
release against the forecast, which is why the purchase order is identified as
When parts come into the ordering window, the buyer releases a requirement. The ordering window is generally determined by supplier lead time, ordering lead time, transit time and occasionally other factors such as incoming inspection time. In the simplest case, a purchase order is generated and transmitted, and in subsequent generation of forecast data, those schedules are marked as firm and the PO number is included with that schedule in the forecast file. In-transit and receipt data are not included in the planning forecast. Only open schedules, firm and planned, are included. The buyer should consider a schedule to be open until parts have been received.
Releases Against Material Release and Embedded Release Forecasts
For material release, the release mechanism (authorization to commit resources and ship) depends on whether the Classic Material Release or Embedded Release process is being used. The release of the delivery schedules (migration of forecast status from planning to firm) is controlled by the buyer. When parts come into the ordering window, the buyer releases a requirement. As with discrete POs, the ordering window is generally determined by part lead time, ordering lead time, transit time and occasionally other factors such as incoming inspection time. As mentioned in the "Lead Time for Releases" discussion below, the difference in a material release environment is that the part lead time is much shorter.
When Blanket Purchase Orders (BPOs) are used as the
foundation of the Classic Material Release and Embedded Releases processes, even though
intuitively releases are being made against the forecast, from a systems and legal
perspective, releases are actually being made against the BPO.
In Embedded Release, the seller simply sees the migration of the forecast status from planning to firm in the forecast file; no discrete release transaction is sent.
Classic Material Release
In Classic Material Release, the recommended release mechanism is that which is recognizable as release against a blanket purchase order (BPO), as opposed to a traditional stand-alone purchase order. While to the buyer the difference between one release mechanism and another may be insignificant, to the seller there is a definite difference in processing. A release against a BPO has much less overhead associated with the processing, whereas a traditional (new) stand-alone purchase order has the overhead associated with validating things like price, ship-to-address, availability, etc. A traditional stand-alone purchase order transaction is usually used as a release against forecast only when using the traditional Planning Forecast (Forecast / Planning Model 1), which does not use a BPO as its foundation.
Recommendations about releases are discussed in "Implementation Recommendations - Blanket Purchase Order Transactions" (July 1997).
Lead Time for Releases
In a forecast environment, there
is no such thing as a "change order" or a "release change." This means
that once a requirement is released, it is truly firm and should not be changed. Because
demand can fluctuate from week to week, and because releases should not be changed,
ideally requirements should be released as close as possible to shipment time.
The "release-to-ship window" is the length of time it takes from the time a release is sent to the supplier to the time the order can be shipped. If the buyer is specifying shipment dates on orders or releases, release-to-ship window and ordering lead time are one and the same. If the buyer is specifying delivery dates on orders or releases, ordering lead time is the combined value of release-to-ship window and transit time.
If there are contractual commitments in the Classic Material Release and Embedded Release process, whereby the buyer agrees to liability for resources and materials within certain time windows, the release lead time can be set to a minimal value (virtual zero lead time). Depending on the timing for transmission of Embedded Release forecasts Discrete Releases, the buyer and seller may agree to set the ordering lead time value to an appropriate value.
Supplier Managed Inventory - Buyer Visibility of Shipments
By definition, in an SMI process, the seller determines when it is appropriate to ship parts, so it is inappropriate for the buyer to issue releases. To enable the processing of an incoming shipment from a seller in an SMI environment the buyer may need to receive advance notification of the shipment via EDI in a Ship Notice / Despatch Advice transaction. It is up to the seller to provide such advance notification of scheduled shipments to the buyer in a timely manner. The ASN may be used for two purposes in SMI:
Parts are normally put on this type of process if there is high assurance of supply - the buyer can count on parts being there when they are needed. However, the buyer may receive visibility of planned shipments in order for the Receiving department to be able to plan workload. The buyer can receive visibility of planned shipments via an Order Status Report. In this case, the Order Status Report is not necessarily used as an acknowledgment to the forecast, but could be.
The general recommendation for forecasts is the same
as for Purchase Orders. To achieve efficiency in processing, and to reduce the amount of
data that needs to be exchanged and processed, any information that is static, or is to be
applied across all forecasts exchanged between trading partners, should be covered in a
Terms and Conditions agreement or other applicable type of contract.
Types of things to be covered in a contract may include:
Authorization (Commitment to Resources)
The EDI 830 transaction and DELFOR message allow for authorization to be specified for manufacturing labor and/or materials. It is recommended that all authorization and liability be covered in the contract.
TCA Reference on BPO
The contract is then referenced on the BPO, and only information which is specific to the individual order needs to be processed by the trading partners. This eliminates the need to transmit a lot of redundant data with each individual BPO.
Types of things usually specified on individual BPOs may include:
Finally, the forecast itself need only contain that information which is critical for processing the transaction / message. These things would include:
This document assumes that a for forecasts processes using a BPO, business agreement exists which defines all standard, basic trading terms and conditions as agreed between the buyer and seller, and that the BPO constitutes a business transaction under this agreement.
Last updated 27 December 2002