- Transportation Lanes are critical master data for APO.
- We cover the Transporation Lane logic, the logic of the Transportation Lane view, Product Specific Transportation Lanes, how to Transportation Costs control the flow of material with the cost optimizer in SNP, Transportation Lane lot sizes in SAP, and more.
Lack of Financial Bias Notice: The vast majority of content available on the Internet about SAP is marketing fiddle-faddle published by SAP, SAP partners, or media entities paid by SAP to run their marketing on the media website. Each one of these entities tries to hide its financial bias from readers. The article below is very different.
- First, it is published by a research entity.
- Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department.
Introduction: How Transporation Lanes are Setup in APO
Transportation Lanes connect the nodes in the network. Transportation lanes are a complex and multifaceted master data object in SAP APO with enormous settings. You will learn about the many settings of Transportation Lane.
What is Transportation Lane?
The following description of a Transportation Lane by a Rajendra on the SCM-APO forum at www.sdn.sap.com.
“Transportation lanes control the material flow along the supply chain. Defines the transportation method, ie., means of transport( might be Truck, Plane, Ship etc ) Also determines the transportation cost, transportation capacity by volume, weight etc. Defines the transportation cost per unit, product and transportation method.You can find the scheduling agreements that you had created in R/3, the planned delivery time etc..”
Transportation lanes are the second major master data object after the location. It determines how a material will flow through the supply network. Frequently, a transportation lane is described as a lane between two locations. That is its general definition outside of SAP and works well enough when discussing SNP. However, there are actually several variations of a transportation lane, which are important to understand and which can be seen clearly in the transportation lane setup. Therefore, a transportation lane is all of the following:
Dimensions of the Transportation Lane
- A relationship between two locations
- A relationship between two locations for a particular product
- A relationship between two locations for a Means of Transport (MOT)
- A relationship between two locations for a Transportation Service Provider
Transportation lanes connect locations, but transportation lanes do not connect all location types. For instance, shipping points and MRP areas are within locations connected to other locations by transportation lanes. Conversely, some locations that are not real physical locations are connected to other locations with transportation lanes. Transportation lanes are created automatically in APO through the CIF when Scheduling Agreements, Contracts, or Purchasing Info Records (supplier records) exist in the SAP ERP system. This is shown in the screenshot below:
When one selects the Purchasing Info Record button, the options to the right appear, and the transportation lanes are created only for the entered selections.
However, when internal locations are brought into APO through the CIF, transportation lanes are not created; they must be manually created instead.
Transportation Lane Field Categories
Transportation lanes have many fields designed to meet a wide variety of functionality needs, with only a subset of these related to supply network design. Likely, implementation will only activate a small number of these fields, but you should understand all the fields or at least those related to supply planning for our purposes. I have reviewed all of the fields in the transportation lanes and organized them into the following categories:
- Time Horizon, Calendar, and Timing Related Fields: Transportation lanes have quite a few timing fields. However, none of the timing fields are pertinent to the supply planning design. Furthermore, I cover these fields extensively and all other time horizons, calendar, and timing fields across the four most commonly implemented APO modules—DP, SNP, GATP, and PP/DS—in my book, Planning Horizons, Calendars and Timings in SAP APO.5.
- TLB Related Fields: Those related to controlling the transportation load builder (TLB)—some of which are also timing related fields.
- Resource-Related Fields: While not often employed, transportation resources can be used and even constrained in SNP. However, it very rarely is. More on this topic is covered in this article:
- Cost-Related Fields: For use by the SNP Optimizer.
- SPP Related Fields: Some of the transportation lane fields are used by a parallel supply planning application to SNP called SPP (service parts planner). This application is unrelated to SNP and is customized for the service parts industry—combining both supply planning and demand planning for the unique planning needs of service parts. I will not cover SPP fields in this article.
- Fields for Setting Up the Supply Network: These fields are relevant to our purposes here and are listed and described below. Three different types of transportation lanes that can be set up in APO:
- a. Transportation Lane Header: This is basic information to establish the connection between two locations.
- b. Product Specific Transportation Lane: A transportation lane can be valid for all products or valid for only some products. Products that are not valid for a transportation lane are excluded from the Product Specific Transportation Lane. On the other hand, different values (such as different transportation costs, lot size profiles, stacking factories, etc. can be applied to different products along the same transportation lane. The fields can have different values per product by creating different product specific transportation lanes. When there is no desire to differentiate among products, and no need to exclude products per transportation lane, there is no need to create product-specific transportation lanes. Instead, a company can set up either multiple—or even a single—means of transport and not create product-specific transportation lanes.
- c. Means of Transport (MOT): The mode of transportation (rail, truck, air, ship, etc.), as well as the equipment (twenty-foot container, forty-foot container, etc.) that is valid along the Product Specific Transportation Lane.
- d. Product Specific Means of Transport: These are the relevant fields for transport for the specific product. This has the fewest fields of the three different transportation lane settings and, in fact, at many companies, is not even used.
Judging by how many times the transportation lane setup has to be explained on projects, transportation lanes are a more challenging master data object or set of master data objects (depending on how you look at it) in APO. The screenshots on the following page are designed to explain how transportation lanes are set up.
First, we will need to choose a model name, a start location, and a destination location.
Here we are selected on the second pane down on the left. In the right pane, the Means of Transport (MOT) view is shown. The MOT represents a specific piece of transportation equipment.
One misleading aspect of transportation lanes is that it seems as if the MOT is created in the transportation lane user interface. In fact, it is only assigned here, in conformance with SAP’s standard approach to an assignment between objects. I find the MOT Transportation Lane to be a relatively misleading configuration area. There are seventy-seven fields between the MOT Transportation Lane and the MOT (which I will show below). However, only two fields on the MOT Transportation Lane are also on the externally-defined MOT: the Means of Transport Name and the MTr Description. When an object is assigned to a profile, its values do not populate a screen.
The object is assigned to a profile in the same way as a TLB (transportation load builder) profile, except that all MOT information shows on this screen. The various MOTs are defined in a different transaction (shown on the following page) and actually are assigned to the transportation lane header. A MOT can be valid for all products or can be specific to one product.
Here is where the MOTs are defined.
Once the MOT is defined, you can go into the transportation lane transaction and assign it to a transportation lane header.
The next step is to create the product-specific transportation lanes, which define the system’s supply source—essentially a series of switches, which set up the valid location-to-location combinations in the network. Product-specific transportation lanes can be blocked or unblocked, allowing the supply sources to be changed very quickly. Changing the blocking indicator is very easy to do. Some clients create a customized procedure that reaches out and changes the blocking indicator based upon a table that is maintained by a group responsible for sourcing decisions. This solution turns out to be a far better way of managing multi-sourcing than attempting to activate APO’s multi-sourcing functionality.
Transportation Fields for Setting Up the Supply Network
The following fields are pertinent to the supply network design:
- Indicator for Use in Aggregated Planning: Indicates whether an entry is used in aggregated planning. Aggregated planning is covered in that this transportation lane is considered by the SNP heuristic for direct deliveries from a production location to a customer location.
- Direct Delivery: Specifies that this transportation lane is considered by the SNP heuristic for direct deliveries from a production location to a customer location. Thus, there is no detour via a distribution center (DC). This field is relevant to supply network design because it defines a different route that circumvents the DC.
- Source of Supply (i.e., Procurement Relationship Type): Indicates the category of procurement relationship. The options are: contract, scheduling agreement, or purchase info record. “Purchase info record” is the most common source of supply. The field is somewhat confusing because “source of supply” typically means the location or locations from which the supply is being sourced (as in the “source of supply” described in Chapter 2: “Locations in APO”). Probably a better name for this field would be the “Procurement Relationship Type,” because if you look at its definition, that’s exactly what it is.
- Distribution Priority (i.e., the Deployment Quantity): The sequence determines where requirements in deployment are processed using the Fair Share Rule D. The distribution priority refers to the transportation lane’s target location. The highest priority is, therefore, priority “0.” For instance, let’s say that two target locations (A and B) each have a requirement of 100 pieces. In source location C, the available-to-deploy quantity (ATD quantity) is 150 pieces.6 Location A has distribution priority 1, and location B has priority. In this case, location A would be assigned 100 pieces, and location B remained fifty pieces.
- Procurement Priority: This is used both by the initial supply plan and by the deployment plan. This field defines the priority of a source of supply in source determination. The highest priority is priority “0.” In Production Planning and Detailed Scheduling, the system uses additional criteria for source determination, such as costs. If the procurement priority is the same, the system selects the source with the lower costs. For deployment, you use the procurement priority to determine the sequence of source locations from which real time deployment is started if you are using this for a destination location. The SNP and deployment optimizers only take this field into account if you use automatic cost generation,7, and have set the indicator on the Procurement Priority of PPMs/PDSs or Procurement Priority of Transportation Lanes in the SNP or deployment optimization profile. 6. Blocked Indicator for Source of Supply: This blocks the use of the product specific transportation lane (it is applied to the product-specific transportation lane). This field provides a great deal of flexibility to the configuration of the supply network. While we speak of “a supply network,” in fact, there are many supply networks. A product may be valid for every location or may only be valid for a “subnetwork.” When the Cost Optimizer is used, this is called “product decomposition” and is the main way the optimizer decomposes or divides the problem.8 The blocked indicator can be adjusted in the transportation lane, or large numbers of product-specific transportation lanes can be updated using MASSD—the mass maintenance transaction in SAP APO. In this way, the product-specific supply network—or the series of product-specific supply networks—can be very fluid and can change depending upon the time of year, special conditions, etc.
Available to Deploy
For those unfamiliar with the term “available to deploy” (ATD), the planned stock-on-hand is available to be sent from a location. It is similar in concept to the available-to-promise quantity (ATP), but instead of promising stock, it is the quantity to be sent. ATD is highly customizable and is assigned to the SNP 2 tab of the Location or the Product Location Master (that is, the ATD rule can be applied at both intersections). ATD is assigned to both the receipt field (what the product location can receive) and the issue field (what it can send). The ATD is used for both TLB and deployment. Of all the supply planning runs, the least emphasis tends to be placed on deployment and redeployment.
The set of master data objects that SAP has created to make up the transportation lane is complex and requires a high maintenance level. A transportation lane is made up of a variety of master data categories.
In just one of the transportation lane master data categories (the Means of Transport Transportation Lane)—combined with an externally determined master data object—and as I have already pointed out, there are seventy-seven fields in these transportation lanes. Transportation lanes in APO were not designed to be efficiently implemented or easily understood; they were designed to offer the maximum functionality and to allow SAP to say “yes, we can do that” to more requirements during the sales process. The complexity of transportation lanes prompts many companies to minimize the number of transportation lanes they must maintain. For instance, many companies want to plan from one set of locations, but then in execution, change the locations that are the source of supply. They want to create confirmed stock transport requisitions (from deployment) from location A to destination B in APO) and eventually create a stock transport order from location B to destination C.
How Are they Normally Created?
When Purchasing Info Records, Scheduling Agreements are CIFed over to SCM Transportation Lanes are automatically created. However, you can go into (/SAPAPO/SCC_TL1) and set them up there if you need to create them. However, when we go to do this, we find that the transportation lane has already been created, most likely from our purchasing info record that we CIFed over earlier.
Really, these should come across from the CIF, unless the SCM instance is stand alone from SAP ERP.
There are five different ways to created Transportation Lanes.
- Using the transportation lane maintenance screen
- Using SCE
- Transportation lane mass maintenance
- Transferring Purchasing Info Records (our preferred way for the sake of simplicity, of course, this will not do when we need transportation lanes between internal plants/locations for transfer orders.)
- Transferring the special procurement key
Important Features of Transportation Lanes
The transportation lanes and product assignments that are created must only represent valid planning options. However, a location/product record must exist at both the source and destination location for specific products assigned to a transportation lane. Location/product combinations are maintained in SAP ERP. However, not all locations are linked by transportation lanes. As a practical matter, if all locations were linked via transportation lanes, the number of lanes would be significant and difficult to validate.
One of the most common planning exceptions is where supply (product or stock) exists to fulfill a demand (sales order, forecast). But no valid transportation lane/product assignment exists to link the two. Therefore the transportation lanes must be set up for all valid location combinations. This is easy to do to setup using the mass maintenance transaction.
What Types of Data are Part of Transportation Lanes
Transportation Lanes allows you to define the product procurement parameters like lot sizes, cost functions, unit costs, and lane priorities. To define each lane’s transportation methods and related parameters like transport costs, distances, and times. Assign product-specific transport methods, assign carriers to the lanes. You can use transport bucket resources to model the capacity of transport fleets to avoid overloading them.
Transportation Lanes and The Supply Network
Transportation lanes, along with locations, combine to form the supply network. They come across from SAP ERP – in the translation of purchase order info records and scheduling agreements. However, they can be created in SCM individually and in batch. They are used in the following SCM modules:
They are not used in the other SCM modules because the other modules do not deal with the overall network’s problem. The modules above are multi-location decision modules. To see where transportation lanes have their effect on SCM, see the following posts.
Transportation Lane Config
The transportation lane seems like kind of an afterthought in an implementation. The concept being that the data is CIFed over, the lanes come and end of the story. However, when you open up a transportation lane in SCM, it becomes apparent how much there is to the lane regarding configuration fields.
The Transportation Lane Hierarchy
In SAP SNP, transportation lanes have a hierarchy to them. The hierarchy is the following:
- Product Specific Transportation Lane
- Means of Transport
- TSP for Means of Transport
The Logic of the Transportation Lane View
The overall logic of the transportation lane view is that there are three panes.
While there are three panes, in fact, the logic is as if there are four panes. The first pane would be the transportation lane, which is not shown in a pane, but as the screen’s header value. This is because the left panes’ logic is primarily an assignment of the products first to the transportation lanes and the products to the means of transport. This feature is often missed because the transportation lane screen does not delineate this fact, and it is not obvious from the interface. However, this is the relationship shown below.
Transportation Lane Means of Transport and Product Relationship
There are simply too many fields available in all the different transportation lane panes.
There are over 50 fields available, and that is unnecessary complexity. The vast majority of these fields are not used by the clients I have worked with. I should not be able to write a small book on the SAP SNP transportation lane functionality.
In contrast to the SAP SNP interface, I will go through the transportation lane hierarchy as it should have been listed:
Product Specific Means of Transport
This level has the smallest amount of information. It declares the validity of the product to means of transport (in this case, truck). It also states the costs, which are used by the SNP cost optimizer. However, it would be used if any other method were used. It has a transportation lot size. This is the minimum lot size that the mode (in this case, the truck can ship with).
The final field is the Stacking Factor, which supposedly determines how pallets can be stacked. However, there are no options when one selects the dropdown. This is essentially a level of detail that SAP would like to get to but lacks the functionality. I have never seen any client use this field, and from its behavior, assume it is non-functional.
This configuration screen does not have all that many options. The primary information is
- The Product
- The Means of Transport
- (if the optimizer is used) The Costs
- The Lot Size
Means of Transport
The next level in the hierarchy is the Means of Transport. This is confusing because it is both the mode (truck, train, plane), as was the particular equipment type. The Means of Transport and the TLB Profile (transportation load builder) have a one-to-one relationship. Therefore, if there are two different truck sizes, two various means of Transport line items would have to be created (at least two, I should say).
This view possibly should have been called the “Vehicle” or the “Specific Vehicle.”
“This is taken into account by the SNP Heuristic, SAP SNP optimizer, deployment and the TLB.” – SAP Help
This quote makes sense until the quote extends to TLB and the TLB Profile. The TLB Profile is already assigned to the Transportation Lane. The relationship between the TLB Profile and Transportation Lane seems to have been designed to maximize confusion. I have written an article on this exact relationship. This article can be seen in this article.
The TLB is simply far more complex in how it is assigned to the transportation lane than necessary.
This setting screen is concerned with most of the real detail in the transportation lane. It contains the following.
- The Duration
- The Distance
- The Resource
- The TLB Profile which is assigned
- The Pull in Horizon
- Whether the truck is straight or loads balanced (different types of products in the same truck, rather than the same types of products).
See this link to be taken to part 2 of this topic.