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
 Order Models Index | Supporting Documentation | Downloads | FAQs |
EIDX Order Models - Supporting Documentation
Releases Against Forecasts and Blanket Orders
Special Notes:   

 


Definitions

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.


Types of Releases

Discrete Releases

850/ORDERS/3A4 vs. 860/ORDCHG/3A8 vs. 862/DELJIT/4B3  <write-up here is at outline stage and is to be expanded>

Release types - Buyer-Managed Inventory environment: (all material in this section is to be rewritten)

Non-Forecast Environment

If parts are not suitable for a forecast environment, releases may be sent in a Change to Blanket Order transaction (860 or ORDCHG) per EIDX Order Model 2 (releases via Change Order) or Order Model 4 (replenishment based on consumption).  Releases are distinguished from Changes to the Blanket Order in the Purchase Order or Message Type coding (see “IDENTIFICATION OF CHANGE ORDER TYPE”.

Releases may also be sent in an 850/ORDERS transaction/message, even though a release is in effect a “change” to an existing BPO.  However, only new releases, not previously transmitted, may be sent using 850/ORDERS.  Changes to releases are to be sent using an 860/ORDCHG transaction/message.

Typically in a non-forecast environment, releases are triggered either to replenish goods that have been consumed, or based on spot demand. The release should be transmitted only once at the time of release.

Forecast Environment

Releases in a forecast environment using BPO's should be sent embedded in the 830 or DELFOR, or issued as discrete releases in an 862 or DELJIT message.  A Discrete Purchase Order transaction is 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.

BPO, Supplier-Managed Inventory, Consumption-based

See also Identifying Order Type and Subtype.


Distinguishing Between Releases and Changes to Releases

To distinguish between newly released schedules and changes to existing schedules, it is necessary to interpret the change order type in the header.  See IDENTIFICATION OF CHANGE ORDER TYPE at the header level above.

For releases and changes to releases in the non-forecast environment, quantity and date changes are allowed (reschedules) at the schedule level.  However, when parts are set up on a process which involves contract agreements and blanket purchase orders, the process usually involves an agreement that the seller will have a certain amount of stock available and be able to ship as soon as a release is received; therefore releases should have short lead times and changes to releases should be avoided.

A newly released schedule should be sent once and once only; thereafter, a released schedule should only need to be sent in a Change to Release transaction/message.

In the case of schedule changes on a Change to Release, recommendations in “EIDX Implementation Recommendations for Change Order Transaction (860), Change Order Acknowledgment (865) Transaction” generally apply.

<This is from fcmodl_support.html - more needs to be moved from there to here>.  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.

Likewise, in a non-forecast environment, changes to releases should be an exception, rather than the rule.  The stability of the demand, albeit un-forecasted, should be one of the criteria for choosing to put goods or services on a blanket-order process.

Refer to “ALLOWABLE BLANKET PURCHASE ORDER CHANGES” above for a description of what changes are allowed in which type of Change Order.  Neither the X12 nor the UN-EDIFACT code list for the line item change type elements have a code which means “Release”.  It is recommended that a generic “change to line item” code be used, since the fact that the change order is a release is indicated in the transaction/message header.

X12 POC02 (DE670)

MEANING

COMMENT

CA

Change to Line Item

Use for original release

Other Codes

Various meanings

Use for change to BPO, change to release

UN LIN.1229

MEANING

COMMENT

3

Changed

Use for original release.

Other Codes

Various meanings

Use for change to BPO, change to release


Release Numbers

Changes to BPOs

If the change is to the Blanket Order itself, and applies to all open and future releases, do not use a release number.  See also CHANGE ORDER SEQUENCE NUMBER”.

Consumption-Based SMI

Release numbers are not appropriate in Consumption-Based SMI, since the seller determines when to ship product.

Release Numbers Not Used

Some trading partners that manage Blanket Purchase Orders may not use release numbers in their BPO's.  Typically, these trading partners do so because there is no demonstrated need, in which case, release number may be seen as irrelevant, and the release number is not needed in response documents such as acknowledgments, ship notices and invoices.  Trading partners should be prepared to accommodate this type of situation; if the receiver’s application must have a customer release number, dummy values might be calculated by the application interface program; likewise, the buyer’s application might be coded to ignore the dummy release numbers if they are sent in a response document.

Release Numbers Used

If release numbers are used by the buyer, it is because it is an important field in the buyer’s application.  It is often part of the key along with the purchase order number when matching the sent 860/ORDCHG change order transaction to the received 865/ORDRSP change order acknowledgment transaction.

Release Number - Header or Detail

Some trading partners’ systems assign releases at the header level of a release transaction, and others assign release number at the item level, and still others assign them at the schedule level.  Trading partners should discuss this as part of the implementation process.

In the ASC X12 standard, release number is carried as a header level element in various beginning segments, including BEG, BCA, BFR, and BSS.  It can also be carried elsewhere in REF segments.  In the EDIFACT standard, release number can be carried anywhere in a message, using the appropriate level RFF segment.  In current EIDX guidelines, release number is allowed for at the header level or the item level.  In EDIFICE guidelines, release number is allowed only at the item level.

It is recommended that release number be assigned at the item level.  Single-item BPO's will help to accommodate trading partners who maintain release numbers at the header level.  In this case, since a transaction will contain only releases for one item, release number may be carried at the header level, and trading partners who need to treat is as item level detail may do so.

Release Numbers - Detail Level

Whether or not to use release numbers and when to carry release number at the header level or detail level are described above under “Release Numbers” at the Header level.  To summarize:  Release numbers are not always necessary but may be used if they are important to the buyer.  Release levels may be carried at various levels; EIDX recommends that release number be carried at the item level.

Assigning Release Numbers

In X12, Release Number may be carried at the item level either in the POC segment of the 860 Transaction, using ‘RN’ as the code value in DE 235, or it may be carried in the POC.REF02, using ‘RE’ as the code qualifier in REF01.  EDIFACT uses the SG28.RFF (C506.1154) to carry Release Number.  In order to be consistent EDIFACT, it is recommended that the REF segment be used in X12 to carry Release Number.

Release numbers and releases per transaction set

Multiple releases for the same item may be sent in one transaction set, but each release should be sent as a new release once, and once only.  One release number should be assigned for the transaction/item, regardless of the number of schedules released.  If multiple releases are issued on the same day for the same item, but in separate transaction sets, each transaction/item should be assigned a new release number.

Example 1 - Non-JIT

Example 2 - JIT

Schedule

Release Date

Rlse Nbr

Schedule

Release Date/Time

Rlse Nbr

100 960205

960129

1

10 960205

9602050815

1

100 960212

960129

1

10 960205

9502050915

2

100 960220

960212

2

10 960205

9502051015

3

100 960226

960212

2

10 960205

9502051115

4

Codes for Identifying Release Number

X12 REF02 (DE127)

MEANING

COMMENT

RE

Release Number

Self-explanatory

UN C506.1153

 

 

AAN

Delivery schedule number

Self-explanatory


Schedules:  Which to Send

BPO's with Delivery Schedules (Scheduling Agreements)

In the case of BPO's with pre-determined delivery schedules, recommendations in “EIDX Implementation Recommendations for Change Order Transaction (860), Change Order Acknowledgment (865) Transaction” generally apply.

Changes to BPO's without Delivery Schedules

Since the BPO has no schedules, there are none to change.  A schedule is added by sending a release.  A schedule that has been released is changed or deleted (canceled) in a Change to Release.


Allowable Changes to Releases

Header and Item Level Changes

Header level changes are not allowed for releases.   Header information changes should be sent in Changes to BPO's.

Schedule Level Changes

Forecast Environment:  Releases and Changes to Releases

For parts that are suitable for a forecast environment, releases should be handled per the appropriate Forecast/Planning Model.  Recommendations for Forecast/Planning Models are being published in a separate document.  Changes to Releases in a non-forecast environment are also dealt with in that document.

Non-Forecast Environment:  Releases and Changes to Releases

Schedule level changes are not appropriate for BPO's that have been issued without pre-defined schedules.  Schedule changes for this type of  BPO are really Releases or Changes to Releases.

Only schedule level changes are allowed for Releases and Changes to releases.  SCHEDULE level changes are used to convey releases against BPO's in the non-forecast environment.  The Blanket Change Order should not be used to convey releases in a forecast environment.

For releases and changes to releases in the non-forecast environment, quantity and date changes are allowed.  However, when parts are set up on a process which involves contract agreements and blanket purchase orders, the process usually involves an agreement that the seller will have a certain amount of stock available and be able to ship as soon as a release is received; therefore releases should have short lead times and changes to releases (which could only be cancels or reschedules) should be avoided.

Recommendations in “EIDX Implementation Recommendations for Change Order Transaction (860), Change Order Acknowledgment (865) Transaction” generally apply to releases in the blanket purchase order process. Exceptions/additional recommendations for BPO's are included below.


Number of Releases per Transaction/Message

Multiple releases for the same item may be sent in one transaction set, for example, in a JIT environment, releases for a part for the next n hourly deliveries might be sent.  However, each newly released schedule should be sent once, and once only.  One release number should be assigned for the transaction/item, regardless of the number of schedules released.   If multiple releases are issued on the same day for the same item, but in separate transaction sets, each transaction/item should use new release numbers.  Releases for multiple line items may be sent in one transaction set or each item may be sent in a separate transaction.  Capabilities for processing multiple releases per transactions or multiple items per transaction should be discussed between trading partners during the implementation process.


Acknowledgments/Responses to Releases

Non-Forecast Environment - Acknowledgments to Releases

The need for acknowledgments to releases in a non-forecast environment should be discussed between trading partners during the implementation process.   If parts are expected to be shipped shortly after a release is received by the seller, acknowledgment may not be necessary.  If the release lead time is longer than a day or two, acknowledgments may be required by the buyer.

Non-Forecast Environment - Acknowledgments to Releases

The need for acknowledgments to releases in a non-forecast environment should be discussed between trading partners during the implementation process.   If parts are expected to be shipped shortly after a release is received by the seller, acknowledgment may not be necessary.  If the release lead time is longer than a day or two, acknowledgments may be required by the buyer.


Last updated 01 February 2003