Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
 Forecast/Planning Models Index | Supporting Documentation | Downloads | FAQs |
EIDX Forecast/Planning Models - Supporting Documentation

Data Requirements for Forecast/Planning Processes

Special Notes:           

See also Order Contents and Data Requirements

Special Notes:           


Forecast Contents and Data Requirements

This section contains a "technology-independent" view of the data requirements for Forecast/Planning requirements.  The individual business content and technology standards have specific requirements - see Index of Cross-Reference of Business Processes and Business Documents for more information.

Basic data items are common to many forecasting processes:

In addition to basic data items, different forecast types have different purposes and different data contents.  These contents are analyzed in:


Delivery Schedules - What to Send

The released and planned schedules should be in chronological customer request date order.  Firm (released) schedules should be reported first, followed by planned schedules.

Reporting Open Orders and Releases (Backlog)

In the Embedded Release Replenishment Scenario, releases are, by definition, included in the forecast data file.  For all other forecast types, it is matter of debate as to whether firm demand (open orders or releases, a/k/a backlog) should be reported in the forecast file send to a supplier.  Some suppliers want firm demand reported so that they can validate it against the data in their order management system.  Other suppliers want firm demand excluded because it will cause a double-counting of requirements.  Some buyers' applications allow them to include firm demand in the forecast file, and some do not.  Trading partners should always discuss expectations for reporting backlog as part of the implementation process.

Reporting Releases

A release should appear only once, whether it is an Embedded Release in the forecast file, or a reporting in the forecast file of a discrete release that has been issued.  Ideally, product has shipped and been received by the next generation of the transmission.  However, if forecasts are sent weekly, and the current week’s forecast shows a release for product that is to ship on the first day of the following week, the forecast file generated in the following week may show that releases and the new release for the subsequent week.  Trading partners should be prepared to handle this type of situation.  See the discussion in Section on Lead Time for Releases for more discussion on this issue.

Matching Schedules to Effective Dates of the BPO

BPOs may be issued with effective dates that do not match the forecast horizon dates of the MRP.

In the case of evergreen BPOs, it is appropriate to send all planned schedules, even if dates extend beyond the expiration date of the BPO.  The expectation is that if the commitment is renewed, the expiration date of the BPO will be updated accordingly.  The TCA should call out what the expectations and liabilities are for schedules that extend beyond the current expiration date of the BPO.

In the case of non-evergreen BPOs,  a single BPO will be issued that covers a given time period.  If this is the only BPO open, all schedules, including those which are past the expiration date of the BPO may be sent.  When a new BPO is issued for the new time period, its effective date should be the day after the expiration date of the older BPO.  There should be no gap in dates that the BPOs cover.  Schedules should be matched according to the effective and expiration dates of all the open BPOs for the part.

Example:  BPO 12345 is effective 950101 through 951231 and BPO 98765 is effective 960101 through 961231.

Schedule Match to BPO
12/01/2001 300 12345
12/15/2001 200 12345
01/02/2002 200 98765
01/15/2002 100 98765
02/01/2002 100 98765

If forecasts are sent with BPO at the header level, this may mean that more than one transaction set will be sent for an item, one for the forecasts associated with the older BPO, and one for the forecasts associated with the newer BPO.

 

Zero Quantities and Schedule Changes

How schedule changes and zero quantities are handled should be discussed between trading partners.  In the past, it was recommended that if a forecasted quantity is rescheduled to another date from the previous transmission of the forecast, a schedules should be sent with a zero quantity and the previous date in order to delete the given schedule.   If it is possible, this is still recommended, for reasons described below.  However, many companies are moving to next generation forecasting solutions, and most are working with third-party solutions.  Many of these new solutions do not allow zero forecasts either to be sent or to be received (without causing the recipient to code in special programming to handle them).

Systems generally handle zero forecasts in one of two ways:


If  it is possible, it is recommended that zero forecast be sent.  This would be particularly important for schedules that are close to lead-time.  The zero quantities alert the trading partner that something has changed.  If the schedule has changed, but the part is still being forecasted, the zero quantities make it easier to identify where the schedule changes were.  If all schedules go to zero, a zero forecast alerts the trading partner that demand for a component or assembly requirement has ended, either because the item is being obsoleted, or because some other supplier has won the continuing business.  The trading partner can then change or change the pipeline as needed.

In addition,  if the entire forecast for a part goes to zero, when you don't send a zero forecast, you just don't send the part.  Then trading partners call and say "What happened to part so and so?"  They may not assume that zero means zero - they may assume that the part is missing from the file.

If systems simply do not allow the sending or receiving of zero forecasts, trading partners should work out alternatives for how they will identify critical forecast changes, part obsolescence, and so forth.

PREVIOUS
SCHEDULES

CURRENT SCHEDULES,
ZERO FORECASTS NOT SENT

CURRENT SCHEDULES,
ZERO FORECAST SENT

01/01/2002

300

01/25/2002

300

01/01/2002

0

01/15/2002

200

03/15/2002

200

01/15/2002

0

02/01/2002

100

04/01/2002

100

01/25/2002

300

 

 

 

 

02/01/2002

0

 

 

 

 

03/15/2002

200

 

 

 

 

04/01/2002

100

Total Qty

600

Total Qty

600

Total Qty

600

 

Schedule Date and Time Qualifiers

In X12, the date qualifier is sent at the header level on the BFR.  In EDIFACT, it is sent at the schedule level.  EIDX recommends the following codes as the date qualifier in the schedule segments:

X12 DE675

EDIFACT DE2005

RNet OAGI

Meaning

DL

2

No code* No code*

Delivery Date

SH

10

Ship Date

*In the RosettaNet and OAGI XML standards, it is not possible to specify a schedule date qualifier; forecast schedules are assumed to be delivery dates.  The trading partners should specify how to interpret the dates in the TCA.

The ship versus delivery codes must be accurate.  Otherwise, the shipment may not be planned for the appropriate date.  For example, if a code indicating “Delivery Date” is used when “Ship Date” should have been used, the seller may be planning to ship on the day that the buyer is planning to receive the parts.  The results will be acceptable only if the transit time indicates same day delivery.

Forecast-Based SMI
There is no distinction between ship date and delivery date in Supplier-Managed Inventory.  Dates sent in schedule segments represent the date the sender plans to consume demand.  Since neither X12 nor EDIFACT have a code which means “consumption date” or “usage date”, it is recommended that the schedules be coded as delivery dates, since this still conveys to the seller the date that the buyer needs the parts to be in house.

Last updated 04 January 2003