Solving 

SAP STO
day to day issues
 
Solving Day-to-Day Delivery Issues While Processing Stock Transport Orders

After users create a stock transport order (STO) in SAP ERP Central Component (SAP ECC), they are not able to
create an outbound delivery for the STO.

For example,  there might be an urgent delivery to be loaded on a truck, but the truck is standing still because the
user cannot create a delivery. Sometimes users can even see the stock in the system, but still the system is not
creating a delivery. In most cases, the most common transactions involving delivery of materials are the ones that
become stuck. The user was able to create a delivery a day before, but today the user is stuck. In another scenario the
system allowed the user to create an outbound delivery for an STO, but the system is not allowing the user to post a
goods issue for the delivery. In this example, the user is able to see the stock in the system, but still the system is not
enabling the user to post a goods issue. There was no con guration change or process change, but suddenly things
became stuck.

These problems are common to all types of STO processes, such as intracompany, intercompany, and STO at storage
location level. So what went wrong? I describe several business problems faced during STO delivery processing and
then explain how to solve them.

(Note: I assume that the user has the required authorization access to all the necessary transactions for the process.
I also assume that all the required system con gurations are in place for the STO scenario to function. I do not cover
the details related to authorization and con guration in this blog.)

A User Can Create an STO, But Cannot Create an Outbound Delivery

Medium-sized to large organizations complete many intercompany and intracompany transactions. Most of them
are handled through an STO. Many users in a supply chain organization in a warehouse or as part of the purchasing
team perform these transactions daily.

The problem of being able to create an STO, but not being able to create an outbound delivery can occur in a new
implementation, rollout, or even a mature system. It can be caused by security, training, or con guration issues. It
may even be a data issue. I explain how to identify which type of issue your system has and also how to eliminate it.

The STO Is Subject to a Release Strategy

Consider a scenario in which an organization has established that a user is the correct person to execute transaction
code VL10G (Documents Due for Delivery) or VL10B (Purchase Orders Due for Delivery). This user has the
required access, but still is unable to create a delivery for the STO.

Perhaps this organization is using a release strategy for STOs. According to this strategy, the organization monitors
the system to ensure that no unnecessary documents are created. With each transaction, time and overhead costs
are involved, so many organizations think it is a good idea to use a release strategy to control overhead costs and
reduce wasted time.

Page 1
If the user can see the Release strategy tab at the STO header level after executing transaction code ME23N, this
means the STO is subject to a release strategy (Figure 1). If the Release indicator box has a status of X Blocked, this
means the STO is still not approved and cannot be processed further.

Figure 1 — STO is blocked

So what should the user do? In most cases the demand from the receiving plant is urgent and important. The
material to be transported is required in a critical business operation or process, and the receiving location is
pressing hard to get this material. The user needs to nd out from the purchase order (PO) work ow log who the
required approver is and why it is not approved. If the approver has missed this item and can approve it quickly,
follow up to get this done. If the approver is on leave or is not the correct one, then the user needs to ask the
technical team to delegate this approval.

The Shipping Tab Is Not Present at the Item Level or Is Not Populated Correctly

Now the organization knows that the user has the required authorization and the STO is approved for further
processing, but the user still is not able to create a delivery.

After executing transaction code ME23N, the user needs to look at the item level of the STO and select the Shipping
tab (Figure 2).

Figure 2 — Check the Shipping tab

Page 2
If the Shipping tab is missing or not populated correctly, the user of the system may face one of the following issues:

  he STO con guration is incomplete

Incomplete con guration normally is not an issue in a mature system. However, it could become an issue in a mature
system if a new organization element such as plant, shipping point, or storage location is added to the system. This
new organization element was not originally meant to be used for STOs, and therefore, con gurations were not
done. In this case, the user needs to ask if the transaction he or she is trying to complete has a valid business case.

If it is established that the transaction has a valid business case and needs to be done, then the user needs to work
with the technical team to con rm if the required con gurations for the STO scenario to work are in place or not.

The user can ask the technical team the following questions to con rm his or her understanding:

I  s the customer number (ship-to party) maintained for the receiving plant? The ship-to party is the goods
recipient here.
 A re the sales (sales org, distribution channel, division) maintained for the supplying plant? This information
helps the system determine shipping data for the material, including the shipping point.
 Is the shipping point determination con guration in place? If the shipping point determination is not correct
or not done, the STO process cannot be achieved.

If STO con guration settings are not correct, it means these con guration settings were sent to production without
proper testing and need to be xed. The test cases for STO scenarios also need to be updated to include this
particular case.

Some master data elements also need to be considered along with the con guration.

The user should check whether the material master is created and extended to both the supplying and receiving
plants. The user should also check whether the material master record is extended to the required storage location.

To complete these checks, execute transaction code MM03 and try to display data for the highlighted views for the
supplying plant (storage location) and receiving plant (storage location) as shown in Figure 3.

Page 3
Figure 3 — Check that the material master is created and extended to both the supplying and receiving plants

If the user can view the data, the system does not have any issues. If the user cannot view the data, the user needs to
contact the master data team to have these views maintained properly.

The material master should be created and extended for the required sales area. To complete this step, the user
executes transaction code MM03 and tries to display data for the highlighted views for the sales area (sales
organization, distribution channel, and division) as shown in  Figure 4. The user needs to enter the plant where
required.

Page 4
Figure 4 — Check that the material master is created and extended for the required sales area

Again, if the user can view the data, then the system is free of any issues. If the user cannot view the data, however,
then he or she needs to contact the master data team to have these views maintained properly.

The vendor master also should be linked to the customer master. To check if it is linked, the user executes
transaction code XK03 (Display vendor [centrally]). The user can then select the Control tab of the vendor master
and check if the customer is maintained or not.

Page 5
The customer maintained in the vendor master should be extended to the required sales area for creating the STO.
To check if the customer is maintained, the user executes transaction code XD03. In the screen that appears, the
user can enter the customer number and sales area to check if he or she is able to display the required data.

If the user has any issue with the vendor master or customer master, then the master data team needs to correct this.

Stock Data Issues

By now the organization has established that the user has created the STO, the Shipping tab at the item level is
properly populated, and the STO is approved for further processing. This means all the required con guration
settings are in place and master data is correct.

If the user still cannot create a delivery for the STO, then this means the problem is with stock data. Stock data is the
inventory on hand for the material for which the STO is created.

Stock on Hand Is Not Suf cient

The user needs to check if there is enough stock on hand to create a delivery using transaction code MMBE. In this
transaction the user provides the materials and supplying plant. As shown in  Figure 5 the user should be able to see
suf cient stock in unrestricted stock.

Page 6
Figure 5 — Check stock on hand

If stock on hand is not suf cient, then delivery will not be created. The required stock should be at the plant and
storage location level of the supplying plant. If the material is batch managed, then suf cient stock at the plant and
storage location should be available for the required batch for which the STO is created. Suf cient stock means
stock equal to or greater than the STO quantity.

Page 7
If the stock is not there, then the user can’t do much and must wait until the stock is available. The stock could be
physically present in the warehouse, but not be re ected in the system. In this case the user can discuss the issue
with the supplying plant warehouse manager. A quick physical inventory document can be created, and physical
stock can be made available in the system.

In all other scenarios, the user can inform the receiving location about the situation and ask the receiving team to
identify a different source if it’s urgent.

Stock on Hand Is Suf cient, But the User Receives an Error Message

Sometimes in an SAP system a user can see suf cient stock on hand, but while creating an outbound delivery using
transaction code VL10*, he or she receives the following error message: “No schedule lines due for delivery up to the
selected date.”

To understand this issue, the user has to go back to the STO after executing transaction code ME23N and check the
Delivery Schedule tab at the item level (Figure 6).

 
Figure 6 — Check the committed quantity on the STO

Here the user can see the information in the following elds:

  elivery Date: This eld displays the date entered by the user when the material is required or adjusted by the
D
system by means of an availability check.
 Sched. Qty (schedule line quantity): This eld shows the quantity required by the user on the delivery date.
 Committed date: This eld displays the date on which the system can supply the schedule line quantity.
 Committed quantity: This eld is for the quantity available on the committed date.

Page 8
Delivery Schedule with the Committed Quality Present

If a delivery schedule line with a committed date and quantity is present in the Delivery Schedule tab, then a simple
trick is to expand the date selection of VL10* and run the transaction again to include the delivery date. This action
creates an outbound delivery in most cases. If the delivery date is way in the future, the user needs to check what the
speci ed interval for the warehouse is, within which he or she can create deliveries.

Delivery Schedule with the Committed Quality Not Present

If a delivery schedule line with the committed date and quantity is not present, then a stock issue needs to be
analyzed further to understand why this is happening. This means that the system ran the availability check and was
not able to con rm any quantity for this particular STO. During an availability check, the system considers open
quantities, receipts, issues, and other commitments.

The user needs to work with his or her location planning manager to understand the situation and how to get a
committed schedule line for this STO. This can be done by analyzing the stock requirements list. To view the stock
requirements list, execute transaction code MD04. In the screen that appears the user enters the plant and material
to see the stock requirements list. Figure 7 shows a typical stock requirements list.

Page 9
 

Figure 7  — A stock requirements list

The planning manager can identify which unwanted reservations or deliveries are consuming stock as in the case
shown in Figure 7. These unwanted deliveries or reservations can be deleted to make the stock situation look better.
The user can then try to go in the STO in edit mode and save it again to check if a delivery schedule with a committed
quantity is created. If not, then this process can be repeated until all unwanted or unnecessary deliveries or
reservations are deleted.

Redistributing a Document Using Transaction Code V_V2

Another option is to redistribute a document using transaction code V_V2 (Updating Sales Documents by Material).
After executing transaction code V_V2, the user can do rescheduling (Figure 8). This transaction allows the
redistribution of already con rmed quantities to other documents.

Page 10
Figure 8 — Options for rescheduling sales and stock transfer document by material

The Updating Sales Documents by Material transaction takes the selected documents and uncon rms them all. This
is to recon rm them based on the con guration set to ne-tune the sorting.

Figure 8 shows the various options. This access should remain only with the planning manager and should be used
with proper analysis only.

STO Committed Date Becomes 12/31/9999

Page 11
In some cases, the user sees that the STO committed date has been set by the system as 12/31/9999. This means the
system was not able to con rm any quantity on the given delivery date. To remove this error, the user or planner has
to ensure that there is enough stock for the requested material on the given date.

Delivery Is Created with Zero Quantity or Partial Quantity

Sometimes the user sees that the delivery is either created with 0 quantity or with a partial quantity. This means the
system was able to con rm only that much on the delivery date. Partial quantity is only created if partial quantity is
allowed in the system.

Outbound Delivery Is Created, But the User Cannot Post a Goods Issue

The next level of the challenge is when the delivery is created, but the user cannot complete a post goods issue for
this delivery.

I now describe some of the reasons for this issue.

Stock Is Not Suf cient

The stock was moved after delivery creation to ful ll some other urgent request. The movement of the stock created
a shortfall in stock, and therefore, a goods issue could not be posted. In this case the user can contact the warehouse
manager to understand the stock situation and nd out how soon the stock can be arranged. If the user can see that
the stock is physically present in the warehouse, but not in the system, then he or she can discuss this issue with the
warehouse manager. They may decide to do an ad hoc physical count to get the stock in the system.

Serial Number Is Not in Stock or Is Not in the Correct Status

If the material is managed by a serial number, then the required serial number should be attached to any other
transaction, and this number should be in the available status so that it can be issued to the correct delivery. If there
are issues with the serial number status, the user rst needs to make sure that the serial number is in stock at
warehouse and then contact the asset management team to ensure that the status of the serial number is correct. If
the serial number is not in stock, then the user needs to contact the warehouse manager to understand which other
serial number can be issued in this case.

Stock Not in the Correct Batch

If the material is batch managed, then the user needs to make sure the correct batch is issued. The user can check if a
batch-to-batch transfer is required to move stock in the correct batch before issuing.

Stock Not in the Correct Storage Location

Page 12
It can happen that the required stock is at the location, but posted in a different storage location. In this case the
user needs to bring the stock to the correct storage location to issue the stock. This can be done by a transfer
posting.

In this blog I have tried to analyze common everyday problems that users face while working with STOs. The list may
not be exhaustive, but it covers up to 90% of the issues and provides enough information for the users to solve their
problems.

The issues can be broadly classi ed as follows:

  uthorization issues
A
 Con guration-related issues
 Master data issues
 Stock issues

All daily business problems cannot be anticipated, but if the users follow a systematic approach as described in this
blog, I am sure they will be able to solve their problems

Page 13