Using the new features available for stock transport orders (STOs), you can deploy STOs more easily and to more business scenarios. Tracking processes are simplified and increased visibility is evident across the supply chain, which eliminates the need for several custom workarounds. For example, these enhanced STO features ease replenishment to customer-facing sites (e.g., retail locations or inventory being held as consignment at a customer site) that maintain service levels. They also alleviate the amount of required data maintenance to transfer excess inventory and other returns to distribution centers and manufacturing plants.

STOs are widely used to distribute inventory in the network. You can create STOs by using the special procurement functionality in material requirements planning (MRP). Logistics tracking is handled using a delivery note, which is a logistics document that reserves inventory for an outbound inventory transaction, such as a sales order or STO. The outbound delivery note can provide an advance shipment notification (ASN) to customers and serves as the basis of the logistics shipping function. In the context of STOs, the delivery note generates all required shipping documents and you can view the document flow. For intercompany transfers, you create billing documents in the supplying company code and vendor invoices in the receiving company code.

Since R/3 4.7, the following new functionality is available for STOs:

Specify issuing storage location and determine shipping data at storage location level: This feature is useful to handle STOs between storage locations. You can take advantage of the shipment tracking functionality and set up storage locations at different addresses.

Suppress source list requirement for stock transport orders: Source list requirements involve additional data maintenance. Using this feature, you can avoid burdensome source list maintenance for internal transfers within the network.

Activate available to promise (ATP) functions to create delivery proposals such as sales orders: With the new ATP functionality, you can view supply confirmation on the STO with partial shipments (if allowed), while retaining the original requirement dates and quantities. Partial shipments are possible when the full quantity requested is not available at the same time in the supplying location, but the delivery note is due. In the previous ATP versions, STOs could not show partial shipments.

Update shipping data on the stock transport order line: By default, the shipping data contained in the customer master and material master appears on an STO. The ability to update shipping data on the STO line reflects information closer to the actual shipment data and drives the correct transportation routes (e.g., faster, slower, costlier, or cheaper) based on the situation rather than the default values in the customer master, similar to shipping a sales order.

You can apply these new STO features to more business scenarios, reduce data maintenance, require less overhead (e.g., storage locations suffice in place of plants, in some cases), and provide more accurate delivery dates though ATP. I’ll walk you through each new feature and provide the necessary configuration details.

Specify Issuing Storage Location

The ability to specify issuing storage location in the STO line is delivered in SAP ERP 6.0 and also available as an advance correction for compatibility with R/3 Release 4.7 and later. An STO line is a document line item that includes various shipping information (such as shipment date, receiving address, and pricing). Using this functionality, you can deploy STOs in the following two scenarios:

Scenario 1: Transport inventory between storage locations in the same plant and determine shipping data at the storage location level. If you model storage locations in place of plants in the org structure to enable shipping and inventory transfers to different addresses, you can minimize the number of plants and resulting data maintenance. A storage location is a customer-facing site that tracks inventory transfers using shipping documents. MRP can be run with specific storage location as MRP area.

When inventory and supply quantity is below the demand quantity, an MRP run triggers replenishment. MRP is typically run at a plant level. However, because you define storage locations in place of plants, MRP runs should correspond to the storage locations. In this example, inventory is replenished for storage locations independently, as opposed to planning inventory levels for the plant as a whole.

Scenario 2: Specify an issuing storage location from the supplying plant and determine shipping data specific to this storage location (e.g., shipping point and route). A shipping point is a physical location from which goods can be shipped. For example, if special handling equipment and procedures are required for shipping hazardous material, a specific shipping point with this capability should be determined. This functionality is advantageous for scenarios in which inventory is segregated into specific storage locations (e.g., due to broken or unusable material). These locations can be excluded from the plant-based availability check.

The shipping point determination or the route determination might not apply to a specific storage location. To meet your business requirements, this new STO feature differentiates plant specific data (e.g., shipping data) from storage location specific data. If you configure shipping data for a specific storage location, the data you enter overrides the plant level shipping data. For example, when one storage location has a different address and transportation zone than the plant, SAP ERP reflects this variation. Shipping points are automatically determined based on criteria (e.g., shipping condition or loading group in the material master, supplying plant, and supplying storage location). Routes are also configured based on criteria such as shipping condition, shipping point, and customer master data (e.g., transportation zone, country, and region) at the issuing storage location level, in this example. If this storage location level shipping data is not maintained in the configuration steps below, the plant level data is used by default.

Now I’ll describe the configuration steps required to execute the two scenarios mentioned above.

Configuration Steps

Follow these configuration steps to enable the issuing storage location functionality:

Step 1. Activate the storage location indicator. Follow IMG menu path Materials Management>Purchasing>Purchase Order>Set up Stock Transport Order>Set up Stock transfer between Storage locations>Activate Stock Transfer between Storage locations. In the screen that appears, select the Issuing Storage Location Active check box to enable STOs between storage locations (Figure 1).

Figure 1

Turn on the issuing storage location indicator

Step 2. Set up the delivery type for each document type. Follow IMG menu path Materials Management>Purchasing>Purchase Order>Set up Stock Transport Order>Set up stock transfer between Storage locations>Assign Delivery Type and checking rule according to Storage location to configure delivery type and checking group (which defines the scope of the ATP check) for specific issuing storage locations. If you want to override plant level data and replace it with issuing storage location data, enter the following information for each document type (Figure 2):

Figure 2

Assign delivery type and checking group to document type, plant, and issuing storage location

• Document type in Type field
• Supplying plant in SPlt field
• Issuing storage location in IStLoc field
• Delivery type in DlvTy field

Step 3. Define shipping data. Follow IMG menu path Materials Management>Purchasing>Purchase Order>Set up Stock Transport Order>Set up Stock transfer between Storage locations>Define shipping data for stock transfers between storage locations to define shipping data for stock transfers between storage locations.

In the storage location overview screen that appears, assign the vendor (Vendor), customer (Customer), and sales organization (Sales Or.), distribution channel (Distr. Ch.), and division of the sales area (Division) to the storage location (SLoc), as shown in Figure 3. If you do not enter this information, the plant-specific data is used instead.

Figure 3

Assign sales area and partners to the storage location

Step 4. Configure shipping point determination per issuing storage location. First, maintain the shipping point determination rule by following IMG menu path Materials Management>Purchasing>Purchase Order>Set up Stock Transport Order>Set up Stock transfer between Storage locations>Set up storage location dependent shipping point determination>Define Rule for determination of shipping point. In the control for shipping point determination screen that appears, assign the required delivery type (field DlvTy) to NL, which triggers the L Storage-Location-Specific shipping point determination (Figure 4).

Figure 4

Change the determination rule for required delivery type

Follow IMG path Materials Management>Purchasing>Purchase Order>Set up Stock Transport Order>Set up Stock transfer between Storage locations>Set up storage location dependent shipping point determination>Assign shipping point according to storage location. Click on the New Entries button to define shipping point determination per the combination of shipping condition (S), loading group (LO.), plant (Plant), and issuing storage location (Sto.), as shown in Figure 5. You can maintain one proposed shipping point, and multiple manual shipping points. SAP ERP determines a proposed shipping point automatically. Users can change it to any of the manual shipping points, if required. You might consider this approach for scenarios that consolidate delivery notes in one shipment.

Figure 5

Enter storage-location-specific shipping point determination

Suppress Source List Requirement for STOs

The source list contains the approved suppliers for a material in a plant and purchasing organization. Companies use it to enforce procurement from approved suppliers and uphold contracts. Stock transport orders are used for internal inventory transfers, as opposed to purchase orders from external vendors, so the source list requirement is sometimes an impediment that leads to unnecessary source list data maintenance. Some of these scenarios include replenishment of a warehouse from a distribution center or a manufacturing plant, transfer of inventory for rebalancing, or return of excess inventory to distribution centers.

If you choose to suppress source list requirements for stock transport orders, apply SAP Note 805189. This SAP Note is provided as an optional program correction and is applicable to R/3 Release 4.5 and above. Go to www.service.sap.com and search for SAP Note 805189 for more information.

After applying this SAP Note, you can configure system message 06722 (source not included in list despite source list requirement) to a warning, informational, or error message, depending on whether or not the source list check should be suppressed. To configure the message severity, run transaction OLME and follow Purchasing>Environment Data>Define attributes of system messages>System messages. Add a new entry by clicking on the New Entries button. Set the severity level to W for warning (informational message), E for error (error message), or leave the Cat field blank to prevent all messages from appearing. The source list requirement can’t be suppressed for external procurement because the approved supplier’s functionality should be enforceable for external procurement. Note that the suppress source list feature works when source list requirement is set at a plant level as well as when it is a material plant level.

Activate ATP Functions to Create Delivery Proposals

Prior to SAP ERP 6.0, the availability check results in the STO are stored on the same schedule line that the user enters (requested schedule) in the committed date and committed quantity fields. Partial confirmations are not possible and the full quantity requested can be confirmed on the last partial confirmation date.

In addition to the above functionality, as of SAP ERP 6.0, three new options are available for availability check results on the STO. These options are:

• One-time delivery
• Complete delivery
• Delivery proposal

One of the three new options enables delivery proposals with partial confirmations and the remaining two allow full confirmation, one with a new confirmed schedule line, and one with same schedule line.

Configuration Steps

Step 1. Assign ATP results rule. Follow IMG menu path Materials Management>Purchasing>Purchase Order>Set up Stock Transport Order>Assign Delivery Type and checking rule to control how an option behaves via Rule for adoption of ATP results in Purchasing setting (Figure 6). Available values to enter in the A (ATP) field are shown in Figure 7.

Figure 6

Assign ATP checking results to order type, supplying plant, and delivery type

Figure 7

ATP result options available for STOs

New Options: Functionality with Examples

I’ll illustrate results for each option using the same scenario. Say today’s date is 04/01/2008. 10 quantities were requested on 04/10/2008 in an STO schedule line. The supplying plant ATP check indicates seven quantities are available on 04/10/2008, and the remaining three quantities are available on 04/15/2008. For each set of results, the Statistical delivery date is the original request date.

Results with default option (field value for ATP result adoption set to blank): The user-requested schedule line will be updated with the confirmed quantity and date (Table 1). Rescheduling with this option updates the delivery date and quantity to the current availability scenario (e.g., if the user’s request information is lost).

Results with options for one-time delivery (field value for ATP result adoption set to A or D): The results look similar to the default option, as shown in Table 2. However, rescheduling works differently and it updates only the committed date and committed quantity. Thus, the requested date and quantity are always available.

Results with options for complete delivery (field value for ATP result adoption set to B or U). This results in a new schedule line for confirmed quantity and confirmed date. Rescheduling updates this new line and leaves the requested line intact (Table 3).

Results with options for complete delivery (field value for ATP result adoption set to C or E). New confirmed schedule lines are created for each partial confirmed quantity and date. Rescheduling updates the new lines with the availability situation while leaving the requested schedule line unchanged (Table 4).

Options D, E, and U configure a delivery proposal to pop up on the screen when a shortage is detected on the requested date and allow users to choose between one-time delivery, full delivery, and partial delivery when the transaction is being processed online. When you create STOs using BAPI and other background methods, options D, E, and U behave exactly like A, B, and C respectively. The STO availability Global ATP works with all recent versions starting with SCM 5.0.

One gap that has not been addressed is that MRP and ATP at the receiving plant do not consider the committed dates and quantities on the incoming STO, and continue to work with the requested date and quantity. This leads to incorrect ATP results at the receiving plant, which is the same as if the default ATP procedure was used.

Update Shipping Data on the Stock Transport Order Line

Starting with R/3 4.7, changes to shipping data are allowed on the stock transport order line as standard functionality by using transactions ME21N and ME22N. Figure 8 illustrates an update to shipping data via transaction ME21N. On the Shipping tab, the fields shipping conditions, route, unloading point, delivery type, shipping point, and delivery priority can be freely changed using transactions ME21N, ME22N. Changes are not possible when using old transactions such as ME21, ME27, and ME22. The route determination is re-triggered when shipping data that influences routes is changed, although it is not updated. Note that field selection for each field on the Shipping tab is not yet available.

Figure 8

Shipping data is updated via transaction ME21N

For a fee, SAP offers to enable this functionality in R/3 Releases 4.6B/4.6C. Refer to SAP Note 769579 for more information.

New purchasing BAPIs BAPI_PO_CREATE1 and BAPI_PO_CHANGE can be enhanced to populate and update shipping data using corrections from SAP Note 765494 starting with R/3 4.7. This comes standard as of SAP ERP 6.0.

For releases before 4.6B, the option to change shipping data on STO does not exist, and the option to influence it while creating the STO is available in very limited form, only via user exits in program SAPLV50N. User exit ZZ_SALES_AREA_DETERMINE can be used to determine sales area differently from configuration. Configure the sales area assignment to plant for stock transfer using transaction OMGN. If the sales area needs to be changed, use the user exit ZZ_SALES_AREA_DETERMINE. Similarly, use the user exit ZZ_SHIPPING_ DATA_DETERMINE to determine delivery priority, route, shipping conditions, and shipping point, based on certain fields in the EKPV table. You can access this table via transaction SE12. For more details, refer to SAP Note 303453.