Transportation and Delivery Scheduling

The aim of the scheduling is to determine the goods issue date, loading date, material availability date, transportation planning date, and when necessary a new delivery date. During order entry, each schedule line for an item can contain a requested delivery deadline.

Configuration
Dates in Use
Process logic of the scheduling
Delivery scheduling
Rounding rules
Transportation Scheduling
Precise Scheduling
Route scheduling
Delivery and transportation scheduling with Route Stages
Process logic of the scheduling
Debugging guide for SD scheduling
Special business processes

3rd party processing
Scheduling in Assembly Processing
Scheduling for Make-to-order scenario
Scheduling for Items with Individual Procurement

Additional information

2221849 - Customizing and process flow of SD scheduling
2140434 - Troubleshooting guide for ERP SD scheduling
1579665 - Scheduling - Date lies on a non-working day
1890212 - Delivery date / goods issue date seems to be incorrect
146829 - Process flow of route schedule
546965 - FAQ: Correlation and delivery groups in SD

Configuration

The delivery and transportation scheduling can be activated in the transaction OVLY.
For deliveries you have to consider the setting in transaction 0VLK.

Field 'Rescheduling' controls whether a new scheduling is carried out.

In stock transport documents you also have the possibility to use the SD scheduling functionality. If you do not activate it then an MM scheduling is carried out.
During SD scheduling the system can take into account three different calendars:

Calendar at the shipping point:

This calendar is used for the calculation of the transportation planning date, material availability date, loading date and goods issue date.

Calendar at the route:

If no calendar is maintained at the route then the calendar at the shipping point is used.

In the customer master, you can define Unloading Points. The unloading point determines when your customer is able to receive the goods. You have the possibility to assign a factory calendar and working hours to your receiving point.

The requested delivery date is checked against the factory calendar at the unloading point. If no calendar is maintained then the requested delivery date can lie on non-working days due to your calendar assigned to the shipping point. Please check SAP Knowledge Base Article 1579665.
The check happens in function module SD_DELIVERY_DATE_CHECK. The calendars must be maintained at least three years into the future!

Working times

SD scheduling can be carried out exact to days or exact to seconds. This depends on whether you are working with working times. In the customizing, you have to define working times for your shipping point.
Customizing path: Sales and Distribution -> Basic Functions -> Delivery Scheduling and Transportation Scheduling -> Maintain Working Hours: These working times you have to assign to the shipping point under: Sales and Distribution -> Basic Functions -> Delivery Scheduling and Transportation Scheduling -> Maintain Duration

Replenishment delivery

The flag for the rescheduling (TVLK-NEUTE) must be set to 'X' or 'Y' for the delivery type of the replenishment delivery. Use the Customizing Transaction 0VLK to maintain the delivery type.
A default order type must be assigned to the delivery type (TVLK-DAART).
The flags for the delivery or the transportation scheduling must be activated for the default order type if you intend to use these functions. Use Transaction OVLY to maintain these parameters.

Dates in Use

Goods issue date

In case of backwards scheduling: goods issue date = delivery date – transit time
In case of forwards scheduling: goods issue date = loading date + loading time

The transit time is the time that is required to deliver the goods from your site to your customer. The transit time is defined in the route.

Customizing path: Sales and Distribution -> Basic Functions -> Delivery Scheduling and Transportation Scheduling -> Maintain Duration

The loading time is the time that is required for loading the shipment. It can be maintained as default for the shipping point, for the combination of the shipping point and route or for the combination shipping point, route and loading group.

Customizing path: Sales and Distribution -> Basic Functions -> Delivery Scheduling and Transportation Scheduling -> Maintain Duration

Loading date

In case of backwards scheduling: loading date = goods issue date – loading time
In case of forwards scheduling: loading date = transportation planning date + transportation planning time

Material Availability date

In case of backwards scheduling: material availability date = loading date – pick pack time
In case of forwards scheduling: material availability date = loading date – pick pack time or the current date

The pick/pack time is the time that is required for allocating goods to delivery as well as the time that is required for picking and packing.
The pick/pack time can be maintained as default for the shipping point. Furthermore for the combination of shipping point and route or the combination of the shipping point route and weight group.

Customizing path: Sales and Distribution -> Basic Functions -> Delivery Scheduling and Transportation Scheduling -> Maintain Duration

Transportation Planning date

In case of backwards scheduling: transportation planning date = loading date – transportation planning time
In the case of forwards scheduling: current date or transportation planning date = loading date – transportation planning time

Delivery date

If the requested delivery cannot be kept a forwards scheduling will calculate a new delivery date: Delivery date = goods issue date + transit time

Process logic of the scheduling

Usually the system starts with a backwards scheduling starting from the requested delivery date.

Exception: Transaction Co06 always carries out ONLY a forwards scheduling.

The requested delivery date will be checked against the factory calendar of the unloading point, and the arrival time will be set according to the beginning of the receiving hours, in other words, to the opening time of the unloading point.

From coding point of view this happens in subroutine function module SD_DELIVERY_DATE_CHECK. Please also consider SAP Knowledge Base Article 1579665.

All other dates and times will be determined in backwards scheduling. If one of the dates or times lies in the past the system automatically switches to forwards scheduling.

In transaction OVLY (Customizing path: Sales and Distribution -> Basic Functions -> Delivery Scheduling and Transportation Scheduling -> Define Scheduling By Sales Document Type) you can control that the system does not switch to a forwards scheduling when the material availability lies in the past. Please also check the related debugging guide (SAP Knowledge Base Article 2220102) for further information.

If the system has to switch to forwards scheduling then the transportation planning date or the material availability date will be set to the current date. Starting from this the other dates will be calculated considering the maintained times. The newly calculated delivery date will be checked against the factory calendar at the unloading point and also against the working times.

It can happen that the delivery date and time has to be shifted further into the future. In other words, to the next working day and time of the unloading point. In this case a new backwards scheduling is carried out from that date and time.

These dates and times can still be changed by the route schedule scheduling which is called right after SD scheduling.

Regarding route schedule determination please check SAP Knowledge Base Articles 1750978, 2150219. Please consider the document for route schedule scheduling.

The final result of the scheduling, or better to say, the determined material availability date will be passed over to the ATP check. The ATP check is carried out for this date. If the date can be confirmed everything is fine. If the ATP check can only confirm on a later date then the new material availability date will be passed again to the scheduling and a forwards scheduling is carried out starting from this date.

Time stream

Scheduling uses time streams. The time streams are stored in table TTSTR. Please consider SAP Note 169885 and SAP Knowledge Base Article 2140434.

Delivery scheduling

Times (time duration) needed to carry out certain activities

The loading time is the time in days that is required for loading a delivery item. It is determined from the shipping point, the route, and the loading group of the material.
The pick/pack time is the time in days that is required for allocating goods to a delivery as well as the time in days that is required for picking and packing. It is calculated using the shipping point, the route, and the weight group of the order item.

dates that are calculated on the basis of these times

Start picking and packing activities on the material availability deadline
The transportation scheduling deadline is the date on which you must start to organize the transportation of the goods
The loading deadline is the date on which the goods must be available for loading and on which all vehicles that are required to ship these goods must be ready for loading
The goods issue deadline is the date on which the goods leave the company in order to arrive punctually at the customer location.
The delivery deadline is the date on which the goods are to arrive at the customer location. The difference between the goods issue deadline and the delivery deadline is calculated from the transit time required for the route between the delivering plant and the customer.

Important notes:

If you have maintained the working times in the shipping point, the unit for the time specification is hours, minutes, and seconds.
We may only enter the transit time in days with two decimal places

Rounding rules

If we have not maintained any working times, the system always rounds dates for scheduling up or down according to normal business practice. You can define the rounding period per shipping point in Customizing.

Transportation Scheduling

Times (time duration) needed to carry out certain activities

The transportation lead-time is the time in days that is needed to organize the shipping of the goods. This might include booking a ship and reserving a truck from a forwarding agent. It is defined for a route.
The transit time is the time in days that is required to deliver goods from your premises to the customer location. It is defined for a route.

For each sales document type, you can define whether a delivery scheduling and/or a transportation scheduling will be carried out.

The transit time is not considered if the field ’Date key’ is set to ’V’ (Date of departure from vendor) in the scheduling agreement (button Delivery Schedule Header -> tab Receipt).
Date key 'V' means that the customer picks up the goods at your site and therefore the transit time is not considered.

Precise Scheduling

Scheduling in Sales & Distribution can take two forms: 1) Daily Scheduling, or 2) Precise Scheduling. Precise Scheduling is used if you wish the scheduling results to be displayed to the minute. Daily Scheduling is used if you wish the scheduling results to be displayed to the day.

If the “Working Times” field is populated in the shipping point customising (Transaction OVLZ), precise scheduling is used. When this field is blank, daily scheduling is used.

The working times are maintained in customising. The customising can be accessed via the following menu path:

SPRO - Logistics Execution - Shipping - Basic Shipping Functions - Scheduling - Maintain Working Hours

Within the customising, you maintain “Shift Definitions”, “Shift Sequences” and “Working Times”.

Shift Definition: A shift is defined by stating the validity dates of the shift and specifying the start time & end time of the shift. This example shows a shift definition called "ZNC".

Shift Sequence: A name is given to the shift sequence (ZNC1 in this example). The Shift definitions are assigned to the various days of the week.
Working Times: Working Time is named and Shift Sequence assigned to this working time. For example, Working Time ZNCTEST is created and Shift Sequence ZNC1 is assigned.

Route scheduling

Using a route schedule, you can control periodic customer deliveries of a particular shipping point to different ship-to parties ( in a certain sequence on a certain defined route. The planning is based on calendar weeks. The period unit is a day.

The route schedule function supports the following processes:

Periodic deliveries from a shipping point to stores or customers are planned in advance on the basis of calendar weeks and weekdays, also without reference to particular deliveries.
We adapt the schedules in the specific cases to the planning. For example, you can plan a GI date for a Monday at 8 o’clock, without knowing the exact date or the delivery.
On the basis of this planning, deliveries that are to leave the warehouse at the same time are combined into groups. In Shipping, we can thus distribute the workload by processing these groups.

Questions?

There are no working times maintained in the shipping point
Route Scheduling is not activated for the shipping point (Field TVST-ALW_SW is initial)
Transportation Scheduling is not activated for the sales document type
The Transportation Group maintained in the route schedule differs to the transportation group maintained in the material master
Shipping conditions maintained in the customer master differ to the shipping conditions maintained in the route schedule
The unloading point maintained in route schedule differs to the unloading point in the customer master of the ship to party
The Goods issue time of the route schedule is outside the working hours of the shipping point
The unloading point of the ship to the party only receives goods at particular hours. The calculated arrival time of the goods is outside the goods receiving hours of the unloading point
Route Scheduling is not activated for the sales document type (Field TVAK-RFPA_SW is initial).

Customizing

the route schedule functionality is switched ON in SPRO → IMG → Sales and Distribution → Basic Functions → Routes → Route Schedule Determination → Scheduling with Route Schedule For Shipping Point (field ALW_SW).
the route schedule functionality is switched ON in SPRO → IMG → Sales and Distribution → Basic Functions → Routes → Route Schedule Determination → Scheduling with Route Schedule for Delivery Type (field RFPL_SW).

Delivery and transportation scheduling with Route Stages

Within the customizing transaction "0VTC" for route maintenance, certain fields from the stages (TVRAB) can be used to add them up into the corresponding fields of the route header (TVRO). The SD scheduling is carried out in the function module SD_SCHEDULING. In this function module, only the duration of the route's header TVRO-TRAZTD is used for the determination, but the durations and factory calendars of the corresponding stages are not used. There are currently no plans for enhancing development in this area.

Process logic of the scheduling

Usually, the system starts with a backward scheduling starting from the requested delivery date.
Exception: Transaction Co06 always carries out ONLY a forwards scheduling.
The requested delivery date will be checked against the factory calendar of the unloading point
And the arrival time will be set according to the beginning of the receiving hours
SD_DELIVERY_DATE_CHECK
If the system has to switch to forwards scheduling then the transportation planning date or the material availability date will be set to the current date.
Route schedule scheduling which is called right after SD scheduling. Regarding route schedule determination please check SAP Knowledge Base Articles 1750978, 2150219.
The final result of the scheduling, or better to say, the determined material availability date will be passed over to the ATP check.

Debugging guide for SD scheduling

The flow logic is the following.

First function module SD_SCHEDULING will be called and the material availability date will be determined. This date will be passed to ATP check (see debugging guide for the ATP check).

If this date can be confirmed then the dates from FM SD_SCHEDULING will be taken over.
If the date cannot be confirmed then the ATP check determines the next possible confirmation date.

In this case, the function module SD_SCHEDULING_ATP_CALC will be called with this new date and the other dates will be redetermined.

Function module sd_scheduling - LS_SCHEDEV contains the results of scheduling

PERFORM get_customizing - result in LS_SCHEDDU if_schedule_direction = – then PERFORM schedule_backwards
PERFORM schedule_backwards - In case the date is in the past PERFORM toggle_scheduling in schedule_backwards toggle_scheduling clearing of cs_schedev
PERFORM schedule_forwards
AVAILABILITY_CHECK_CONTROLLER after check calls
ATP_EXPLANATION
DIALOGUE_EXECUTE
SD_SCHEDULING_ATP_CALC
DIALOGUE_DISPLAY
DIALOGUE_FILL
SD_SCHEDULING_ATP_CALC Results in TERM => ATPTERMX

Special business processes

3rd party processing

During the automatic delivery scheduling of third-party items, the system takes into account lead times specified by the purchasing department.

For example, the system allows for the time required by the vendor to deliver the goods to your customer and also the time required by the purchasing department to process third-party orders.

PR: (TVEP-AUBST) Purchase requisition with delivery scheduling

If it is empty, do not clean Scheduling parameters

Include: FV45VFMV_MVERF_AUFBAUEN_WMENG, MVERF_AUFBAUEN_WMENG

Scheduling in Assembly Processing

Starting at the requested delivery date, the system first determines the basic finish date of the production order, planned order or network.
Starting at the basic finish date, the system then determines the committed date of the sales order

Starting at the requested delivery date, the system subtracts the delivery scheduling time, goods receipt processing time and in-house production time.
The next step depends on the in-house production time:

If the start of the in-house production time does not lie in the past (case 1), the in-house production time finish is the basic finish date.
If the start of the in-house production time does lie in the past (case 2), the system adds the in-house production time to today’s date in order to determine the basic finish date.

Scheduling for Make-to-order scenario

The total replenishment lead time (which is found on the MRP 2 screen in the material master) as well as delivery scheduling form the basis for scheduling orders items for make-to-order production.

Unconfirmed order items can be confirmed automatically by updating backorders, when the production dates that prevented the confirmation change. The new, earlier production dates are then copied into the order items.

Scheduling for Items with Individual Procurement

If you create a sales order for which the determined delivery date differs from the requested delivery date, the Purchase Order Scheduling dialog box appears. In this window the determined delivery date is displayed as the proposed delivery date.

If the customer accepts this delivery date, select the Fix qty/date field to fix the date and the confirmed quantity. The provision date determined by the scheduling of the confirmed quantity is copied into the corresponding purchase requisition as the delivery date.

If the customer requests that you deliver the goods earlier than the system can confirm, leave the field empty. In this case the provision date for the requested delivery date is copied into the purchase requisition. This is based on the assumption that it is still possible to deliver on the requested delivery date by shortening the procurement lead time, for example.

During the automatic scheduling of individual purchase order items, the lead times determined by Purchasing, such as the delivery processing time and the purchasing processing time, are also taken into account.

The material availability date, which is related to the material procurement settings, determines the scheduling for a sales order item with individual procurement. This date is the end point of procurement scheduling and the starting point for determination of a delivery directly to a customer.

The determination of the material availability date is based on the following Customizing and master data setting:

Processing time, in working days, required by the purchasing department to convert a purchase requisition into a purchase order
Planned delivery time, in calendar days, maintained in the plant data of the material master record and purchasing info record
Good receipt processing time, in working days, maintained in the plant data of the material master record
Factory calendar of the delivery plan

The starting point for procurement scheduling is the release date of a purchase requisition for a sales order item with individual procurement. The system adds the purchase requisition processing time (in working days) and the planned delivery time (in calendar days). If the resulting date is not a working day, the next working day is set as the vendor’s delivery date to the delivery plant. Finally, the goods receipt processing time is added (in working days) to determine the material availability date.

To avoid early confirmation, when the BAdI calculates a delivery date that is earlier than the requested delivery date for a given sales order item, this date is ignored. Instead, the material availability date calculated by the system is set as the delivery date. Use the business add-in BAdI: Determine Delivery Date for Items with Purchasing (BADI_SD_TPO_IP_DELIVERY_DATE) to implement your own logic to determine the vendor's delivery date to a delivery plant more accurately. The system will still add the receipt of the goods processing time to your delivery date to set the material availability date.

When you create a purchase order from a purchase requisition, the system updates the schedule data of a sales order (SO) item according to a change in the delivery date of the related purchase order (PO) item. Subsequent changes to the PO item's delivery date will also lead to an update.

If you have specified a confirmation control key for the PO item with the confirmation category order acknowledgement, the system will update schedule data of the sales order item based on the delivery date of the order acknowledgement item. When updating schedule data, the system takes into account additional order acknowledgement items for partial quantities with different delivery dates. It then creates several schedule lines for sales order item accordingly. Use the Business Add-In BAdI: Update of Shipment Scheduling from Individual Procurement (MM06EF0S_CUSTOMER_SD_UPDATE) to implement your own logic to merge events with different priorities for the update.

Additional information

2221849 - Customizing and process flow of SD scheduling

2140434 - Troubleshooting guide for ERP SD scheduling

Changes in the factory calendar are not considered while scheduling:

The system works with streams during the scheduling. When you e.g. change the factory calendar in your test system then the time stream will be deleted and when needed newly generated. But when you move the changes of the factory calendar to another system (e.g. productive system) via a Transport then the time stream will not be updated. You have to delete the time streams manually. Please consider SAP Note 169885. Whenever you carry out such changes it is recommended to delete the streams via the report mentioned in the SAP Note. The report runs only a few seconds and you will not get any success information when the report has finished. The report can be used safely at any time. The time streams will be automatically generated when needed.

Unexplainable dates are determined while scheduling:

There are several cases where the time stream cannot be built up correctly or where you receive not explainable dates. Usually this is caused by wrong customizing:
Factory calendar validation is not sufficient. Please make sure that the factory calendar is maintained at least three years into the future.
Factory calendars at shipping point, route, unloading point are not harmonized. The same is valid for the working times and the factory calendar at the unloading point. It makes no sense to maintain e.g. working times for Monday whereas it is a non-working day due to the calendar.
Shift definitions for the shipping point are not valid any more. Please make sure that the shifts are valid (Customizing path: Sales and Distribution -> Basic Functions -> Delivery Scheduling and Transportation Scheduling –> Maintain Working Hours).
Inconsistencies in the time stream -> See SAP Note 169885.
In case of time stream type 'TS', the generation of the time stream table is based on the time zone of the shipping point. However, there is an option to generate the time stream based on a time zone which differs from the time zone of the shipping point (Customizing path: Sales and Distribution -> Basic Functions -> Delivery Scheduling and Transportation Scheduling –> Maintain Working Hours -> Working times -> Time Zone / field TZONE). When reviewing the result of the scheduling please make sure that the time stream has been generated by using the correct / desired time zone.

1579665 - Scheduling - Date lies on a non-working day

Customizing:

The delivery date is only checked against the factory calendar of the unloading point of the customer (transaction XD02). Please consider SAP note 547961 question 8. When you enter a delivery date that is a non-working day according to the factory calendar of the unloading point of the customer then you will get a warning message. You can bypass this message by pressing enter. You 'only' get a warning message because the system wants to keep the possibility that you confirm this date despite the warning message. It is possible that the goods are very important for the customer and so the customer is disposed to accept a delivery on a non-working day. When the system cannot confirm the requested delivery date then the system creates a second schedule line for the date when a confirmation is possible. This confirmed delivery date will be also checked against the factory calendar at the unloading point.
If the scheduling is deactivated in transaction OVLY then the factory calendar at the shipping point is not used for the determination of the Goods Issue Date, Loading Date, Material Availability Date or Transportation Planning Date. Therefore, the dates can lie on a non-working day according to the factory calendar of the shipping point.

Inconsistent time stream:

The time stream is a table with generated time slots. This table is used for the scheduling. Sometimes this table becomes inconsistent. This usually happens when you change the factory calendar and/or the working times e.g. in your development system and then you transport these changes to your e.g. test system. You can see the executed changes in your test system but the time stream has not been updated. This means that the time slots of your time stream do not match with your factory calendar and working times. Please consider SAP note 169885. The note contains two reports, ZZTSTRDISP and ZZTSTRDELE. Please use report ZZTSTRDELE to delete the time streams. The report can be used safely at any time. After the deletion of the time streams please check the system behaviour again. The time stream will be generated automatically again as required.

1890212 - Delivery date / goods issue date seems to be incorrect

If there is an unloading point maintained for the customer in transaction XD02, the delivery date will be calculated considering the calendar and the goods receiving hours of the unloading point. Please consider the attached SAP note 1579665 also.

1890212 - Delivery date / goods issue date seems to be incorrect

In sales orders the delivery date and time are expressed in the time zone of the ship-to-party.

Goods issue date/time, loading date/time and material availability date/time are expressed in the time zone of the plant.

146829 - Process flow of route schedule

Unexplainable dates are determined while scheduling:

There are several cases where the time stream cannot be built up correctly or where you receive not explainable dates. Usually this is caused by wrong customizing:

Factory calendar validation is not sufficient. Please make sure that the factory calendar is maintained at least three years into the future.

Factory calendars at shipping point, route, unloading point are not harmonized. The same is valid for the working times and the factory calendar at the unloading point. It makes no sense to maintain e.g. working times for Monday whereas it is a non-working day due to the calendar.

Shift definitions for the shipping point are not valid any more. Please make sure that the shifts are valid (Customizing path: Sales and Distribution -> Basic Functions -> Delivery Scheduling and Transportation Scheduling –> Maintain Working Hours).

Inconsistencies in the time stream -> See SAP Note 169885.

In case of time stream type 'TS', the generation of the time stream table is based on the time zone of the shipping point. However, there is an option to generate the time stream based on a time zone which differs from the time zone of the shipping point (Customizing path: Sales and Distribution -> Basic Functions -> Delivery Scheduling and Transportation Scheduling –> Maintain Working Hours -> Working times -> Time Zone / field TZONE). When reviewing the result of the scheduling please make sure that the time stream has been generated by using the correct / desired time zone.

546965 - FAQ: Correlation and delivery groups in SD

Which functions use correlation?

Correlation is used in the following cases:
1. In sales document processing, a BOM can result in an item category that forms a delivery group.
2. On the item overview screen of the sales order, you can manually enter a delivery group on the "Shipping" tab page.
3. On the item overview screen of the sales order on the "Shipping" tab page, you can set the "Complete Delivery" indicator. Correlation is also carried out in this case as a result.

Delivery group with a common delivery date, that is, that of the latest schedule line.

The correlation of quantities takes place ONLY during the BOM explosion.

If a BOM requires several components, but some of them are not available, the components that are available are correlated.

As a result, the system may issue incomplete sets or bills of material.

The main item (or BOM header) is always confirmed fully if the subitems (components) are relevant for the check (for example, item category group LUMF).

In this case, the main item is not checked and no further quantity correlation is carried out.

For more information, see SAP Note 167328.

Search This Blog

Toolkit for SAP consultants