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.
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.)
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.
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).
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.
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.
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.
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.
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).
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.
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.
The Updating Sales Documents by Material transaction takes the selected documents and unconfirms them all. This is to reconfirm them based on the configuration set to fine-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
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 confirm 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 confirm only that much on the delivery date. Partial quantity is only created if partial quantity is allowed in the system.
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 Sufficient
The stock was moved after delivery creation to fulfill 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 find 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 first 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
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 classified as follows:
- Authorization issues
- Configuration-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.