Supply Chain: Solving Stock Transport Order (STO) Problems
Meet the Experts
by Vineet Pandey, Sr. SAP Consultant, EY
Often 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 configuration change or process change, but suddenly things became stuck.
Explore related questions
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 configurations are in place for the STO scenario to function. I do not cover the details related to authorization and configuration in this blog.)
by Vineet Pandey, Sr. SAP Consultant, EY
Often 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 configuration change or process change, but suddenly things became stuck.
Explore related questions
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 configurations are in place for the STO scenario to function. I do not cover the details related to authorization and configuration 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 configuration 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.
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 find out from the purchase order (PO) workflow 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
If the Shipping tab is missing or not populated correctly, the user of the system may face one of the following issues:
- The STO configuration is incomplete
- The master data is incorrect
Incomplete configuration 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, configurations 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 confirm if the required configurations for the STO scenario to work are in place or not.
The user can ask the technical team the following questions to confirm his or her understanding:
- Is the customer number (ship-to party) maintained for the receiving plant? The ship-to party is the goods recipient here.
- Are 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 configuration in place? If the shipping point determination is not correct or not done, the STO process cannot be achieved.
If STO configuration settings are not correct, it means these configuration settings were sent to production without proper testing and need to be fixed. 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 configuration.
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.
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.
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.
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 configuration 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 Sufficient
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 sufficient stock in unrestricted stock.
Figure 5 — Check stock on hand
If stock on hand is not sufficient, 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 sufficient stock at the plant and storage location should be available for the required batch for which the STO is created. Sufficient stock means stock equal to or greater than the STO quantity.
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 reflected 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 Sufficient, But the User Receives an Error Message
Sometimes in an SAP system a user can see sufficient 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 fields:
- Delivery Date: This field displays the date entered by the user when the material is required or adjusted by the system by means of an availability check.
- Sched. Qty (schedule line quantity): This field shows the quantity required by the user on the delivery date.
- Committed date: This field displays the date on which the system can supply the schedule line quantity.
- Committed quantity: This field is for the quantity available on the committed date.
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 specified 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 confirm 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.
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 confirmed quantities to other documents.
Premium
