Delivery Requests

Delivery requests are orders sent by the customer to the vendor that define the specific quantities of items they need shipped.  The delivery request can refer to several item/delivery point relationships, and cover several delivery periods.  Each delivery period for an item/delivery point is expressed in the form of a delivery request release.  The delivery request is composed of a DR number, a DR date, and time.

Delivery request releases specify quantities required by date or by period by the customer.  The system splits and offsets the delivery request releases into offset releases.  The splitting and offsetting process determines the preparation date and the shipping date of the items to meet the customer delivery due date.  The corresponding requirements are then passed on the Requirements Planning, Master Scheduling, and Just-In-Time modules for planning.

Delivery Request releases by period are split and offset by the system to correspond with that item/delivery point's specific splitting rules if defined in the endorsement.  If no specific splitting rules exist for the item/delivery point, the splitting rules for the bill-to/ship-to customer combination are used.  All delivery request releases (both planned and confirmed) are split and offset for the fine-splitting horizon (see the Splitting and Offsetting Key Concept in this overview for more information).  All confirmed releases are split and offset regardless of whether they are to be delivered in the fine-splitting horizon or beyond.  Planned releases beyond the fine-splitting horizon are split into periodic quantities.  These offset releases are then taken into account during the shipping proposal generation on the day they need to be prepared or shipped to meet the customer delivery date.

For VDA processing, there is a type of release called immediate release, nature "0", which contains immediate requirements and backorder.  This release is considered the same as a firm demand and must be delivered as soon as possible.  Only one immediate release open (day period required) is authorized per link item/delivery point.  This release must be the first release to process and requires at least a firm release, nature "1".  An immediate release can have the same start delivery as the production release.  For example, in ODETTE mode:

In VDA mode:

In the example above, only the two first releases can have the same start date.

For ANSI processing, the system supports firm (nature 1) and planned (nature 2) release natures.  The system uses Reference File category G34  (ANSI Release Nature) to convert ANSI releases in ODETTE format.

VDA FAB/LAB Delivery Requests

For VDA processing, there are two main types of delivery requests:  LAB (delivery request) and FAB (detail delivery request). 

LAB Requests

LAB requests can be used for long term planning and repetitive supply.  LAB requests are long-term procurement requests (6 to 12 months).  LAB requests are contained on record formats 511 through 519 and are indicated by nature types of 0, 2, 3, and 4.  A nature type of 0 indicates backorder and immediate release.  LAB type 2 refers to a production release, type 3 is a material release, and type 4 is a planning release. 

FAB Requests

FAB requests are short-term detailed delivery requests (less than 6 months) for shipments that the supplier needs to deliver to the customer.  FAB requests are contained on record formats 551 through 559 and are indicated by a nature type of 1. 

An FAB may be a period of an LAB.  For example, a customer may have an agreement with a vendor to have 60 cars delivered over the time period of 6 months.  If a customer needs 20 cars in the first month, the shipment of those 20 cars makes up the FAB request.  Thus the FAB is a one-month period within the 6 month LAB request.

Delivery requests also contain:

·     Expected shipments--quantities by date and/or quantities by period. 

·     The identification of the synchronization data between the customer data and vendor data to eliminate any problem concerning the accounting of delivery advance/backorders.  The transmission of synchronization data is optional.

You can input delivery request three ways:

·     Automatic creation from DELINS, VDA 4905/1, VDA 4915, or ANSI X12 830 messages transmitted from the customer.

·     Manual creation through the Delivery Request Maintenance conversation

·     Manual creation through the VDA Delivery Request Maintenance conversation

During the automatic acquisition of DELINS, VDA, and ANSI, the following validations are performed:

·     Transmission check:  if the transmission software detects an error, the system issues a warning, and according  the degree of the error, the whole message will be rejected and must be re-transmitted.

·     Existence check:  the system checks the validity of data  in comparison with the data recorded in the blanket order or the endorsement.  In case of error, all data is saved and a warning is displayed.  You can then modify the request by correcting the error.

·     Delivery request rules:  for the same delivery request and item/delivery point relationship, the successive releases must be in consecutive periods.  No gaps are allowed between releases.  No overlapping of periods is authorized. 

·     VDA message check:  The VDA Delivery Request Validation and Input program (GA209E) handles all VDA type delivery requests sent by customers, validating the requests according to syntax and functional criteria.  The VDA Delivery Request Validation and Input program (GA209E) passes the messages stored in GA210AP4 to the delivery request files.  Two types of delivery request segments are processed during this time:  segments numbered 51X (ex: 511, 512, 513, etc.) correspond to VDA4905 (LAB) delivery request messages whereas segments numbered 55X (ex: 551, 552, 553, etc.) correspond to VDA4915 (FAB) delivery request messages.

During this processing, data is passed from GA210HP2 to GA210HP3 and is then written to either delivery request files or erroneous message files.  Specifically, correct VDA requests are written to the MAC-PAC delivery request files (GA210M1, GA210M2, GA210M3) according to the VDA replacement rules.  Erroneous VDA requests are written to the VDA Delivery Request Error Message file (GA210HP).  These error messages may be updated manually in the VDA Messages Update conversation (GA217E) and processed during the following Synchro batch job.  This processing loop continues until the workfiles (GA210HP2 and GA210HP3) have been emptied or an error occurs. The workfiles are then cleared and the next VDA message is checked (the program checks the VDA counter).  After several levels of validation, the new VDA message is written to the delivery request files.

The system performs the following controls during the VDA validation:

·     VDA segments sequencing.

·     Segments counters (last and current).

·     Existence checks performed against Synchro master files (EDI numbers, endorsement, blanket order, and delivery conditions)

·     Transmission Type:  2 for VDA 4905/1 (forecast) and 3 for VDA 4915 (firm).

·     Synchro VDA forecast periods existence (Reference File category G77 - Synchro/VDA Forecast Dates).

The system executes the automatic acquisition of ANSI X12 830 messages independent of the DELINS/VDA acquisition.  The ANSI acquisition program processes workfiles rather than real EDI files.  The workfiles are created by a third party translation software as the result of a mapping process.  Once the mapping is completed, the system submits the Automatic Acquisition batch program (GA208E) and performs the same controls as for the DELINS/VDA acquisition (GA210E).

If the system detects an error, it sets the error flag of the corresponding record in the appropriate work files (header, lines, or comments) to 'Yes'.  All the transactions in error can be corrected in the ANSI Update conversation and then reprocessed during the next execution of the ANSI acquisition.  The error levels are:

·     Header level.  Example:  the program cannot identify the sender EDI number.

·     Item/delivery point level.  Example:  The program cannot identify the ship-to EDI, delivery point, etc.

·     Release level.  Example:  overlapping between periods, periods not ascending, release nature involved.

The system automatically updates the Synchro master files if the complete message, any part of the message, or at least one item/delivery point is valid.  When messages are processed, they are purged automatically.

There can be only one active delivery request per item/delivery point at a time.  Delivery request releases specify the demand for a minimum of one day.  There can be only one active release per day per item/delivery  point.

The delivery request type determines the way the request is processed against any already existing delivery requests associated with the same item/delivery point relationship.

Three types of delivery requests can be made:

·     Cancel and Replace:  The previous delivery request is canceled and replaced by the new one for the associated item/delivery point relationships, starting with the first delivery date displayed in the new delivery request.  This is the only delivery request type valid for VDA mode.

·     Current Actualization:  New information is substituted to the delivery request  received previously for the corresponding periods.  This type can only modify the nature (firm, planned) and the quantity of the planned releases.  The user can override a firm release by updating Reference File category G23 (Authorization to Change) before actualizing a delivery request.  In acquisition mode, the user can override firm releases by updating Reference File category G31 (Automatic Acquisition DELINS/VDA) for each bill-to/ship-to customer combination required.

·     Synchronization data:  This type is only used in the automatic acquisition of DELINS or VDA messages.  The system uses the information found to update the item/delivery point link (for example the quantity received by the customer for the shipment, last dispatch, advice number, etc.).

You can analyze the variances between the previous delivery request and the DELINS Acquisition in process quantities.  Reference File category H70 provides you with the parameters to define in order to run this analysis.  The results are printed on a report sorted by sender company/warehouse, buyer/analyst code, and ship-to customer.

The delivery request type is specified on the DELINS, VDA or ANSI message by the customer, or entered in the Delivery Request Type field on the Delivery Request Maintenance detail screen or, for VDA mode, entered in the Type field on the VDA Delivery Request Maintenance Release List screen.  For VDA mode, the delivery request type must always be Cancel and Replace.

The following example shows the difference between the two types of delivery requests.  Note that in the type 1, cancel and replace, you can modify the quantities and the delivery period dates.  Type 2, current actualization, allows you to change the item quantity, but you cannot change the delivery periods covered.  Both types of requests allow you to confirm a planned delivery request release.

Related

• Delivery Request Releases