Example: Optional SUT Check When Creating a TO
The system can only find the appropriate storage bins for a storage unit type (SUT) when creating transfer orders if the SUT check is activated. There is a restriction of 10 allowed SUTs per storage type.
You can enter *** as an allowed SUT in this table. This entry means that all the SUTs in this storage type are allowed. The system then searches for a suitable storage bin for the SUT based on the allowed bin types per SUT.
Note
Before implementing this optional SUT check, you should examine the table parameters closely since problems with performance can arise if the configuration settings are not optimal.
The following example outlines the performance problems associated with the optional storage unit type check and their solutions:
Example
For SUT E1, bin types P1 P2 P3 P4 P5 are allowed. They are to be stored in storage type 001. However, only storage bins of the type P0 exist here.
SUT type E1 would not normally be allowed in storage type 001. An efficient system recognizes this (in that it can access a completely buffered table) and continues the search for a place in the next storage type.
During the optional SUT check, the database is accessed 5 times unsuccessfully. This number increases correspondingly if you work with different storage sections.
It is relatively simple for you to check the customizing settings by viewing the log for the storage bin search. The more unsuccessful attempts made, the more ineffective the process becomes. The number of attempts must be reduced by optimizing the storage type search.