Transportation and shipment scheduling involves backward scheduling to determine the requested material availability date based on the customer requested delivery date and then forward scheduling to determine the committed delivery date based on the committed material availability date. If the Available-to-Promise (ATP) check is performed in SAP ERP Central Component (SAP ECC), this scheduling is based on logistics configuration — shipping points or routes. However, if the ATP check is performed in SAP Advanced Planning & Optimization (SAP APO) Global Available-to-Promise (Global ATP) it is not possible to carry out the transportation and shipment scheduling in SAP ECC. You must then use one of the several options that are available in SAP SCM to perform transportation and shipment scheduling. One of these options is Configurable Process Scheduling (CPS). While it is the most flexible approach, it is also the most complex and probably the least documented method.

In this article, we aim to fill the gap in the documentation of CPS. We outline how transportation and shipment scheduling for sales orders and stock transport orders can be enabled using CPS in the context of an ATP check using Global ATP. Specifically, we will discuss the business requirements and configuration steps.

Business Requirements

There are three main approaches to transportation and shipment scheduling using standard configuration in Global ATP, which we will summarize with the following scenarios:

• Scheduling using CPS

• Scheduling using Supply Network Planning (SNP) Master Data. This includes product and location master data as well as transportation lanes (the transportation lane is an arc from a source location to a destination location and specifies the transportation duration for different modes of transport).

• Scheduling using condition technique

Note that the options outlined are not mutually exclusive. For example, it is possible to use CPS as the scheduling technique while still using SNP master data wherever available (as you will see in the “Define Schema” section of this article).

Regardless of the scheduling method used, the inputs to the scheduling process are the order characteristics (such as shipping location and receiving location). The outputs of the scheduling process are key event dates such as material availability date (MAD), goods issue (GI) date, loading date, and delivery date. Those dates are used by the ATP check and returned back to SAP ECC in the form of schedule line dates.

The system tries to perform scheduling by trying to find the relevant data in this order: CPS, SNP master data, and finally, condition technique. It goes from one option to the next only if the prerequisites for the previous option are not met.

Scheduling Using Configurable Process Scheduling

CPS can be thought of as an SAP SCM application that can be called by other applications (in this case, Global ATP), to perform transportation and shipment scheduling. CPS can perform scheduling that is more complex and can be used in situations in which the simpler methods described previously cannot meet the business requirements. For example, take a situation in which a business wants to ship regular priority orders on weekdays only, but wants to ship rush orders on weekends. Such a requirement can only be handled by CPS. This is not to say the CPS should only be used when the scheduling function is complex. The release restrictions of SAP SCM 5.0 (SAP Note 832393) for Backorder Processing of Stock Transfer Orders suggest that for the results to be consistent with liveCache you should use CPS.

liveCache is a memory resident database that is part of the SAP APO design. SAP APO applications such as Global ATP use liveCache for faster data retrieval from memory and processing as opposed to access from a disk. Synchronization between liveCache and the SAP APO database is an activity that is automatically taken care of by the system.

Also, CPS allows for retaining the flexibility in scheduling if the business environment changes.­ If the standard activities of scheduling, transportation planning, pick/pack, load, transport, and unload are not enough, CPS allows you to define your own custom activities and to determine their duration and calendar. CPS is also the most complex technique to set up. However, SAP has provided standard content for many objects, greatly simplifying the task of configuring CPS. 

Scheduling Using SNP Master Data

With this technique, transportation lane master data is used to determine transport times. This method is easiest to use when the source and the destination are both locations within the supply chain model. This is true for a typical stock transport order scenario as well as Vendor Managed Inventory (VMI) sales orders, but not necessarily true for other sales orders. For a sales order the destination is outside the domain of the enterprise supply chain. Transportation lanes are usually defined and master data maintained for locations within the supply chain and not outside of it. For example, if we had 1000 customers and 10 DCs, we have to maintain 10,000 transportation lanes and this is not practical.

Typically, the granularity of data supplied by transportation lanes is not sufficient for a Global ATP check. For example, shipping conditions on the sales order determine route duration. While it is possible to map shipping conditions to the means of transport used in transportation lanes, this may be too cumbersome to maintain for SNP purposes. When using SNP master data for scheduling, there could also be potential conflicts in the optimal way to assign time stream calendars to locations (plants) for planning (SNP and Production Planning/Detailed Scheduling [PP/DS]) and Global ATP.

Scheduling Using Condition Technique

The system uses this method only if it does not find configuration for CPS or SNP master data. This method provides a single scheduling schema (SCHEDL) for determining durations for a fixed set of scheduling elements: plan (LEAD), load (LOAD), pick/pack (PICK), transport (TRAN), and unload (UNLD). A disadvantage of this approach is that the condition technique can be used for activity durations only and not for calendar determination. Time stream calendars assigned to locations are still used, leading to potential conflicts with planning requirements.

This condition technique should not be confused with the condition technique used within CPS. Although both are conceptually similar, the configuration required is distinct. Also, CPS is much more flexible and can simultaneously use any combination of condition technique and SNP master data for determination of calendars and activity durations.

Configuration Steps

The configuration steps detailed in this article are based on an SAP SCM 5.0 system integrated with an SAP ECC 6.0 Online Transaction Processing (OLTP) system. This application area has not undergone significant change in newer releases. As always, it is best to use SAP-delivered content for configuration elements wherever possible. At a minimum, CPS should be configured so that the dates and times of activities that are determined through standard scheduling in SAP ECC are still determined through Global ATP — that is, it should replicate the scheduling logic in SAP ECC. While CPS can provide much more functionality than SAP ECC scheduling, it is best to keep the two systems in sync. The logical steps used by the system at run-time to access the configuration elements are shown in Figure 1. 

Figure 1

CPS logical flow

Configuration can be divided into two main sections:

• Schema definition
• Condition technique definition

Transportation and shipment scheduling requires master data to find key dates such as Material Availability Date (MAD) — for example, pick/pack time and calendar. A scheduling schema identifies scheduling elements (activities, date types) that are relevant for scheduling and governs how master data is determined. For example, pick/pack can be an important activity that is defined when using the standard scheduling schema but it could potentially be excluded if you are defining your own schema. In most cases, SAP-delivered schemas are sufficient and no configuration steps are required. However, it is still useful to understand the schema definition in order to understand how CPS scheduling works and to fix any issues that you may encounter. In the examples below, we refer to the standard schema SCHEDL_SDD, but the same steps are applicable for creating new schemas.

To define elements of a schema, follow menu path SAP SCM - Implementation Guide > SCM Basis > Configurable Process Scheduling > Define Elements of Schema. Activity types (Figure 2) model business processes relevant for scheduling. Typical activity types used in scheduling include pick/pack, transport, and unload.

Figure 2

Schema definition (Activity Types)

Date/Time types (Figure 3) model events that represent the start and end times of activity types. These include delivery date (LFDAT) and material staging date/time (MBDAT).

Figure 3

Schema definition (Date/Time Types)

Define Schema

To get to the define schema screen, follow menu path SAP SCM Implementation Guide > SCM Basis > Configurable Process Scheduling > Define Schema. The elements defined in the previous step are now organized into schemas in this step. This can be a technically challenging task and therefore it is best to use SAP-delivered schemas. In most cases, SAP-delivered schemas such as SCHEDL_SDD or SCHEDL are sufficient for sales orders. SCHEDL_MM can be used for stock transfer orders.

If you decide to use SAP-delivered schemas, carefully review the schema definition to determine if the schema meets your requirements. In the business scenario described earlier where it was necessary to have different calendars for regular and rush orders, the SCHEDL_SDD schema (Figure 4) has to be used since the simpler SCHEDL schema does not support the condition technique for calendar determination as delivered by SAP.

Figure 4

SAP-delivered schema SCHEDL_SDD

Activities (Figure 5) identify the business process steps for scheduling. When using standard schemas, we recommend having a schema that has more activities than you think you need. For example, for a typical sales order processing the SLEAD (source determination) activity is redundant but the SCHEDL_SDD schema can still be used if it meets other requirements. It is, however, critical to remember that every activity defined in the schema is used in the scheduling process. Every activity in the schema must have master data that the system should find. More than one activity can share the same condition tables and it is not necessary to use condition technique unless the simpler sources (such as location master) are not sufficient.

Figure 5

Activities for SCHEDL_SDD schema

The derived date types are shown in Figure 6 for schema SCHEDL_SDD. One can think of derived date types as the nodes connecting the activity arcs. These do not take any time but represent the start or finish of schema activities. Derived date types correspond to the dates returned to the calling application. For example, MBDAT corresponds to the material availability date in SAP ECC; LFDAT corresponds to the delivery date and so on.

Figure 6

Derived Date Types for SCHEDL_SDD schema

Property Transformation (Figure 7) determines the master data object mapping between what CPS understands and values supplied by the calling application (in our case GATP that calls CPS functions). For example, to identify the destination node (LOCTO), CPS can use one of several values passed from SAP ECC through the scheduling field catalog  — Destination Plant (LOCTO), Customer Ship-To (KUNWE), or Customer Sold-To (KUNNR) in that order of priority.

Figure 7

Property Transformation for SCHEDL_SDD schema

Another element within the schema is duration determination (Figure 8). This specifies how durations are determined for schema activities. An example of this is the duration for the transport from source location to target location which needs to be determined. In the SCHEDL_SDD schema for example, for the activity PICK, the primary method the system uses is condition record data. Class DURA_COND (duration determination through condition record data) has a higher priority than class DURA_LOCAMDL (duration determination through location master data). This is an example of how CPS can use master data defined through condition records as well as SNP master data (in this case location master data).

Figure 8

Duration determination for SCHEDL_SDD schema

The rest of the schema definition elements such as calendar determination or time zone determination (as shown in Figure 4) follow the same pattern and are not repeated here.

Defining Scheduling Process Models and Process Alias

The menu path to define the scheduling process models and Process Alias is SAP SCM - Implementation Guide > SCM Basis > Configurable Process Scheduling > Process Definition > Maintain Process. The Process Alias is a pointer to the scheduling schema. It is in the scheduling schema that the entire process of scheduling is defined and used by CPS. One can think of Process Alias as the entity that is known to the application (Global ATP, for example) and the scheduling schema is the entity that is known to CPS. The mapping between the Process Alias and the scheduling schema is through configuration.

The scheduling process model (Figure 9) consists of a number of activities and their predecessor/successor relationships (similar in concept to a Critical Path Method [CPM] project network). CPM is a function in which you define the predecessor/successor activities and times for a project, which path takes the longest time and then determine which one you should concentrate on. A simplified workflow editor is used to define this scheduling process model.

Figure 9

Process definition for SCHEDL_SDD schema

The workflow steps are mapped to schema activities through settings in the Properties tab. For example, the Transport step of the workflow WS79400009 is linked to the TRAN activity of the SCHEDL_SDD schema (Figure 10) through the property sap.scm.bas.sch.actitype on the Properties tab.

Figure 10

Transport step in SCHEDL_SDD process definition

A Process Alias links the workflow to the scheduling schema (Figure 11). The menu path to maintain this is SAP SCM Implementation Guide > SCM Basis > Configurable Process Scheduling > Process Definition > Define Process Alias. Both the Process Alias and the scheduling schema must have the same name.

Figure 11

Mapping of Process Alias to workflow identifier