Directory   Messages   Segments   Composites   Data elements   Codes Meaning of the change indicators
  UN/EDIFACT  D.03A (Batch) Syntax version 3 Issue date 2003-06-23  
  Message type specification DELFOR
 
 
* DELFOR 8 Delivery schedule message  
  Date:
2003-06-10

Source:
TBG1 Supply Chain

0. INTRODUCTION
This specification provides the definition of the Delivery schedule message (DELFOR) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.

1. SCOPE

1.1 Functional definition
WARNING! This version of the DELFOR is not upward compatible with versions prior to D02A.

DELFOR is a message which is sent from a party who is planning the use or consumption of products to a party who has to plan for the supply of the products. The message gives the requirements regarding details for short term delivery and/or medium to long scheduling for products. The scheduling can be used to authorize manufacturing and or the provision of materials.

This is based on the terms and conditions defined in a purchase order or contract.

The message may also be sent in response by a party which has received a DELFOR message to indicate to the party which has issued the message, the acceptance of, rejection of, or to propose amendments to the previous message.

1.2 Field of application
The Delivery schedule message may be used for both national and international applications. It is based on universal practice related to administration, commerce and transport, and is not dependent on the type of business or industry.

1.3 Principles
1.3.1 DELFOR used for scheduling and forecasting.

The Delivery schedule message shall be used to:

- specify firm delivery dates and the quantities scheduled (using segment SCC, data element Delivery plan commitment level code (4017)= "Firm".

- specify forecasted production requirements (using SCC, data element Delivery plan commitment level code (4017)=either "commitment for manufacturing and material (2)" or "commitment for material (3)" or "planning/forecast (4)".

- define the aspects that guarantee the synchronization between the supplying and receiving parties, thus allowing the supplier to plan for the resources necessary to fulfill customer requirements.

The Delivery schedule message provides the option to use one of two scheduling methods.

Method 1: delivery point driven
This is when for a given delivery point a number of different products are to be delivered. This means that address information triggers product information. Usage of segment group NAD-LOC-FTX is consequently required for the specification of delivery points.

Method 2: product driven
This is when a given product is to be delivered to a number of different delivery points. This means that product information triggers address information.
Consequently, segment group NAD-LOC-FTX is not to be used.
Delivery point information shall be specified in segment group NAD-LOC-FTX included in the segment group LIN-PIA-IMD.

An initiating Delivery schedule message is identified in the BGM with the "document name code (1001)" equal to "delivery schedule (241)" and "message function code (1225)" equal to "original (9)".

A subsequent message may be used to replace the schedule completely (quantities and dates). This is identified in the BGM with the "message function code (1225)" equal to "replace (5)". The replacement of a schedule requires the new schedule to totally override the previous one.
Alternatively the message may be used to partially alter the schedule. This is identified in the BGM with the "message function code (1225)" equal to "change (4)". Such alteration to the schedule shall adhere to the following recommendations:

1.    All the date information in the QTY-DTM segment group shall be systematically used to identify the group to be changed.

2.    How the information is to be changed:

2.a. To change a quantity - where the date information matches the current quantity is replaced with the new quantity.

2.b. To change a date - the current quantity has to be changed to zero and the new date information has to be given with the quantity from the former schedule.

2.c. To change a date and quantity - the current quantity has to be changed to zero and the new date information has to be given with appropriate new quantity.

2.d. To delete quantities and dates - the current quantity has to be changed to zero.

2.e. To add quantities and dates - the new date information has to be given with the appropriate new quantity.

3.    Unchanged dates and quantities - unchanged dates and quantities from the former schedule need to be resent.

4.    Delivered quantities - delivered quantities are automatically eliminated from the schedule.

The association to the previous Delivery schedule message is given by referencing the appropriate document/message number.

1.3.2 DELFOR used for response purposes.

The indication of a DELFOR message for response purposes is achieved through the use of 'Delivery Schedule Response' code value in data element 1001 of the BGM segment.

When used as a response to a previous DELFOR message the message may be used to indicate one of the following conditions using code values in data element 1225 of the BGM segment:

- Total acceptance;
- Total rejection;
- Not processed;
- Proposal for change.

Total acceptance of a previous DELFOR message may be indicated using code value '29, Accepted without amendment', in data element 1225 of the BGM segment. Where a previous DELFOR message is being totally accepted then only the EDIFACT mandatory segments, and those agreed by the parties exchanging the message which enable the identification of the previous message, need be re-sent.

Total rejection of a previous DELFOR message may be indicated using code value '27, Not accepted', in data element 1225 of the BGM segment. Where a previous DELFOR message is being totally rejected then only the EDIFACT mandatory segments, and those agreed by the parties exchanging the message which enable the identification of the previous message, need be re-sent. If required the reason for rejection may be indicated in the FTX segment at header level using either a bi-laterally agreed reason code, or a free text reason.

Should a DELFOR message have been received but not yet processed through the relevant internal application(s), a response may be issued indicating this fact using code value '12, Not processed', in data element 1225 of the BGM segment.
Where this code value is being used then only the EDIFACT mandatory segments, and those agreed by the parties exchanging the message which enable the identification of the previous message, need be re-sent.

When the party responding to a previous DELFOR message wishes to propose changes to some of the information contained in the previous message, then the code value '4, Change' should be used in data element 1225 of the BGM segment.

If no information at the detail level of the message changes then only the EDIFACT mandatory segments, those agreed by the parties exchanging the message which enable the identification of the previous message, and the segments containing the data proposed for change need be re-sent.

When changes are proposed to data contained at the detail level of the message then the following recommendations should be applied:

1. All the date information in the QTY-DTM segment group shall be systematically used to identify the group to be changed.

2. How the information is to be changed:

2.a. To change a quantity - where the date information matches the current quantity is replaced with the new quantity.

2.b. To change a date - the current quantity has to be changed to zero and the new date information has to be given with the quantity from the former schedule.

2.c. To change a date and quantity - the current quantity has to be changed to zero and the new date information has to be given with appropriate new quantity.

2.d. To delete quantities and dates - the current quantity has to be changed to zero.

2.e. To add quantities and dates - the new date information has to be given with the appropriate new quantity.

3. Unchanged dates and quantities - unchanged dates and quantities from the former schedule need to be resent.

4. Delivered quantities - delivered quantities are automatically eliminated from the schedule.

2. REFERENCES
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 1.

3. TERMS AND DEFINITIONS

3.1 Standard terms and definitions
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 2.

4. MESSAGE DEFINITION

4.1 Data segment clarification
This section should be read in conjunction with the segment table which indicates mandatory, conditional and repeating requirements.

This section should be read in conjunction with the segment table which indicates mandatory, conditional and repeating requirements.

The following guidelines and principles apply to the whole message and are intended to facilitate the understanding and implementation of the message:

All specified dates/times should be in the format 'ccyymmdd'/'hhmm' unless all parties involved in the transaction agree that there is a functional requirement for an alternative format.
Periods should be specified as whole numbers representing the required period as indicated in the format qualifier (weeks, months, etc.)

Where a choice of code or text is given only the code element should be used wherever possible.

Conditional data that is not required in the message should not be included.

Care must be taken that the segment qualifier in dependent segments do not conflict with the segment qualifier of the trigger segment of a group.

Free text information within the message should be avoided as this inhibits automatic processing.
 
  Generated by GEFEG.FX  
  http://www.gefeg.com