Delivery Schedule Validation

Outcome

You know about the details involved in the validation activity and you are familiar with the different fields that control the validation.

You will be able to configure the customer delivery schedule (CDS) process and especially the validation activity in accordance with the customer's and your own requirements.

For further information, refer to Validate a Delivery Schedule.

Before you start

• A partner structure according to Enabling Partner Agreement must have been defined.
• A partner alias connection according to Create Partner and Partner Alias Repositories must have been defined if the DS is created via M3 EDI Solution.
• An item must have been defined in 'Item. Open' (MMS001), 'Item. Connect Warehouse' (MMS002) and 'Item. Connect Facility' (MMS003).
• An item alias could be defined in 'Customer. Connect Item' (OIS005) or in 'Item. Connect Alias Number' (MMS025).

Make sure that the following fields in 'Delivery Schedule Type. Open' (RSS010) have been analyzed and defined:

• '045 Check sequence - item ID' and '050 Search sequence - alias type'
• '055 Next manual function'

Make also sure that the following fields in 'Settings - Partners' (RSS015) have been analyzed and defined:

• '060 Check if quantity split should be performed' together with a split model in 'Delivery Split Model. Open' (RSS055)
• '105 Calculation method for Period to date'
• '120 Consolidate item demands'
• '125 Search standard warehouse' and '130 Search standard facility', see Define Sourcing
• '135 Update package information'
• '140 Date type in delivery schedule'
• '200 Agreement rule' together with a blanket agreement in 'Cust Blanket Agreement. Open' (OIS060)
• '205 Override demand commitment'
• '210 Customer's order number'
• '230 Retrieve item on instruction level'
• '235 Calculate transportation lead-time' and '505 Adjust to delivery pattern', see Enabling Date Calculation
• '315 User exit program - validate'
• '515 Are hours and minutes in use'
• '525 Overriding packaging terms'

Purpose

The purpose of validation is to:

• Retrieve default DS data
• Check mandatory DS data
• Convert EDI addresses and the item alias into M3 identities
• Calculate date and demand data.

When these activities are performed, the DS line is checked to make sure that it contains correct data according to the required DS process. This makes the DS item line ready for activation, which is the next activity in the processing of a DS.

When

Validation is performed when requested from 'Delivery Schedule. Open' (RSS100) or from 'Delivery Schedule. Connect Items' (RSS101). This is described further in Validate a Delivery Schedule.

If the DS was created manually, it will be validated automatically when the demand entry is finished in 'Delivery Schedule. Connect Demands' (RSS102).

If the DS was created via EDI, validation is usually performed automatically.

You choose whether you want the validation to be performed manually or automatically in the '055 Next manual function' field in 'Delivery Schedule Type. Open' (RSS010).

How

Validation consists of several activities, where some are mandatory and some are not. The overview below describes the main steps including the alternatives to initiate validation.

Validation activities

All validation activities are performed automatically in a sequence without any interaction with the user. If any error occurs, the processing is interrupted.

1. Pre-Validation User Exit

   The pre-validation user exit program is run if you need to manipulate DS data before starting the validation.

   Note: This user exit program is used as an exception and can only be run if the '315 User exit program - validate' field has been defined in 'Settings - Partners' (RSS015).

2. Alternatives to Initiate Validation

   Validation is performed when requested from 'Delivery Schedule. Open' (RSS100) or from 'Delivery Schedule. Connect Items' (RSS101).

   You choose whether you want the validation to be performed manually (per line or for the entire DS) or automatically in the '055 Next manual function' field in 'Delivery Schedule Type. Open' (RSS010).

   • If the DS was created manually, it will be validated automatically when the demand entry is finished in 'Delivery Schedule. Connect Demands' (RSS102).
   • If the DS was created via EDI, validation is usually performed automatically.

3. EDI Address Conversion

   The EDI addresses connected to the DS item line are converted into M3 customer, address number and possible delivery specification.

   Address conversion is only performed for an EDI DS. The reason is that the EDI DS includes the partner's own identities for the plant, gate/dock and final destination, and these identities have to be converted into M3 identities. For further description of the conversion of EDI addresses and partner alias identities to M3 identities, refer to Enabling a Partner Alias.

4. Item Alias Conversion

   For an EDI DS, the item alias received in the DS item line is converted into a M3 item number. This conversion is based on the definitions in the '045 Check sequence - item ID' and '050 Search sequence - alias type' fields in 'Delivery Schedule Type. Open' (RSS010).

5. Default Data Retrieval

   Default data, that has not been received via EDI or entered manually, is retrieved. Examples of default data are standard sales unit of measure, facility, warehouse, packaging information, blanket agreement, delivery pattern and currency.

   The data is retrieved according to the settings defined (refer to the Before Starting section) and the hierarchies in M3.

6. Demand Commitment and Demand Bucket Calculation

   The DS item line can be calculated regarding the demand commitment (DC) and demand bucket (DB), if this has been requested in the '205 Override demand commitment' field in 'Settings - Partners' (RSS015) and if the settings in 'Partner. Define Demand Commitment Calculation' (RSS018) have been defined.

   The DC and the DB are managed per demand in 'Delivery Schedule. Connect Demands' (RSS102) and indicate the customer's desired level of commitment and the time period covered by each demand. See Define a Partner Setting for further description of how to enable calculation of DC and DB.

   It is also possible to recalculate DC and DB manually via option 71 = Over demand commitment in 'Delivery Schedule. Connect Items' (RSS101).

   If the demand bucket is not calculated according to above, it will be calculated based on each demand's from date and to date (assuming that the to date was included in the EDI DS). The from date is always the same as the received requested delivery date. DB is then calculated based on the number of calendar days between the from date and to date.

7. Date and Demand Calculation

   Dates and demands are calculated during the validation of the DS. An internal requested delivery date or departure date is calculated based on the received requested delivery date. The calculation is based on date type, transportation lead-time, delivery calendar and the delivery pattern. See Enabling Date Calculations for further description of how different dates are calculated.

   Each demand always has a from date and a to date. From date equals the requested delivery date. If the to date was not sent in the EDI DS, it can be calculated according to the definitions in the '105 Calculation method for period to date' field in 'Settings - Partners' (RSS015). If to date is calculated, the time period is retrieved from the calculated demand bucket.

   The calculated start date/time, calculated end date/time and demand overview fields, that are displayed in 'Delivery Schedule. Connect Items' (RSS101/G) and (RSS101/H), are updated to the DS item line, based on the range of demands.

   If the customer has sent cumulative quantities instead of discrete requested quantities, the requested quantity is calculated based on the difference between each demand's cumulative quantity and previous demand's cumulative quantity. See Enabling Cumulatives for further description of cumulatives.

   If you know that the M3 item number will be changed within the DS time horizon, you can update the demands with different item numbers by activating the '230 Retrieve item on instruction level' field in (RSS015) and also by defining from dates and to dates in 'Customer. Connect Item' (OIS005).

8. Reconciliation Check and Update

   Reconciliation information is checked and updated. Note that this activity is only valid if the DS has been automatically created. The result of the update can be viewed either in 'Delivery Schedule. Connect Items' (RSS101/S) or in 'Delivery Schedule. Connect Demands' (RSS102/B). For further description, refer to Reconciliation of Delivery Schedule Demands.

   Depending on whether delivery note or cumulative reconciliation method has been selected for the '015 Reconciliation method' field in 'Settings - Partners' (RSS015), one of the following takes place:

   • Delivery note reconciliation:

     The customer's received delivery notes connected to the DS item line are matched against the M3 delivery history so that the last received delivery note can be updated to the DS item line. You can view the delivery notes received by the customer in 'Delivery Schedule. Open Delivery Notes' (RSS105).

   • Cumulative reconciliation:

     The cumulative quantity received in the EDI DS is checked, and together with the cumulative calculation date, it is updated to the DS item line. You can view the cumulatives received by the customer in 'Delivery Schedule. Open Cumulative Figures' (RSS104). If it is the first time ever you receive a DS for this customer and item, basic data about the cumulative figures will be created in M3 . If it is the first DS entered since a change of year and the Y2Y calculation has been selected in 'Item. Update Cum Quantities Delivered' (MMS072), the M3 cumulative figures will be recalculated.

9. Demand Split Calculation

   The DS demands will be split during the validation, if this is requested in the '060 Check if quantity split should be performed' field in 'Settings - Partners ' (RSS015) together with a split model defined in 'Delivery Split Model. Open' (RSS055).

   A split is necessary when the received demands are aggregated for a specific demand bucket (for example, monthly demands) and you want to break them down to weekly or daily demands. The reason for doing this is to create a more detailed planning overview and a more correct replacement between forecast and call-off DS.

   It is possible to perform split calculation manually via option 72 = Split in 'Delivery Schedule. Connect Items' (RSS101). The split can also be reversed via option 73 = Delete split in (RSS101).

   See Define Split Management for further description of how to define and calculate a split.

10. Post Validation User Exit

    The post-validation user exit program is run if you want to manipulate DS data before ending the validation.

    Note: This user exit program is used as an exception and can only be run if the '315 User exit program - validate' field in 'Settings - Partners' (RSS015) has been defined.

11. Start and End Date Calculation

    The start and end dates for the DS header are calculated.

    The purpose of this is to update the DS header with the lowest calculated start date/time and the highest calculated end date/time, based on all DS item lines inside the single DS.

12. Application Message Creation

    If the validation is run automatically and ended in some sort of error, then application message type 503 = Validation error for the item, is sent to the responsible user.