You are on page 1of 62

SAP R3 ARCHITECTURE INTRODUCTION

SAP based the architecture of R/3 on a three-tier client/server model.


Presentation Server
Application Server
Database Server
Presentation Server
The presentation server is actually a program named sapgui.exe. It is usually installed on a users
workstation. To start it, the user double-clicks on an icon on the desktop or chooses a menu path. When
started, the presentation server displays the R/3 menus within a window. This window is commonly
known as the SAPGUI, or the user interface (or simply, the interface). The interface accepts input from
the user in the form of keystrokes, mouse-clicks, and function keys, and sends these requests to the
application server to be processed. The application server sends the results back to the SAPGUI which
then formats the output for display to the user.
Application Server
An application server is a set of executables that collectively interpret the ABAP/4 programs and manage
the input and output for them. When an application server is started, these executables all start at the
same time. When an application server is stopped, they all shut down together. The number of
processes that start up when you bring up the application server is defined in a single configuration file
called the application server profile.
Each application server has a profile that specifies its characteristics when it starts up and while it is
running. For example, an application sever profile specifies:
Number of processes and their types
Amount of memory each process may use
Length of time a user is inactive before being automatically logged off
The application server exists to interpret ABAP/4 programs, and they only run there-the programs do
not run on the presentation server. An ABAP/4 program can start an executable on the presentation
server, but an ABAP/4 program cannot execute there.
If your ABAP/4 program requests information from the database, the application server will format the
request and send it to the database server.

Discovering the Database Server
The database server is a set of executables that accept database requests from the application server.
These requests are passed on to the RDBMS (Relation Database Management System). The RDBMS
sends the data back to the database server, which then passes the information back to the application
server. The application server in turn passes that information to your ABAP/4 program.
There is usually a separate computer dedicated to house the database server, and the RDBMS may run
on that computer also, or may be installed on its own computer.
Configuring the Servers
In a three-tier client/server configuration, the presentation servers, applications servers, and database
server all run on separate machines. This is the most common configuration for large systems, and is
common in production.
In the distribution presentation configuration, the application and database servers are combined on
one computer and the presentation servers run separately. This is used for smaller systems, and is often
seen on a development system.
In the two-tier client/server configuration, the presentation and application servers are combined and
the database server is separate. This configuration is used in conjunction with other application servers.
It is used for a batch server when the batch is segregated from the online servers. A SAPGUI is installed
on it to provide local control.
When all servers are combined onto a single machine, you have a central configuration. This is rarely
seen because it describes a standalone R/3 system with only a single user.
Defining an R/3 System
The simplest definition of an R/3 system is one database. In one R/3 system, there is only one
database. To expand the definition, R/3 is considered to be all of the components attached to that one
database. One R/3 system is composed of one database server accessing a single database, one or more
application servers, and one or more presentation servers. By definition, it is all of the components
attached to one database. If you have one database, you have one system. If you have one system, you
have one database. During an implementation, there is usually one system (or one database) assigned
to development, one or more systems designated for testing, and one assigned to production.
The term R/3 system landscape denotes a description of the number of systems within an SAP
installation and how they are designated, such as development, test, or production.
Defining an R/3 Instance
When you hear someone say the word instance, most of the time, that person will be referring to an
application server. The term instance is synonymous with application server.
The term central instance refers to the database server. If an application server and database server
both reside on the same machine, the term central instance refers to the computer on which both
reside.
In the most general terms, an instance is a server. It is a set of R/3 processes providing services to the
R/3 system.
Application Server Architecture
All requests that come in from presentation servers are directed first to the dispatcher. The dispatcher
writes them first to the dispatcher queue. The dispatcher pulls the requests from the queue on a first-in,
first-out basis. Each request is then allocated to the first available work process. A work process handles
one request at a time.
To perform any processing for a users request, a work process needs to address two special memory
areas: the user context and the program roll area. The user context is a memory area that contains
information about the user, and the roll area is a memory area that contains information about the
programs execution.
Understanding a User Context
A user context is memory that is allocated to contain the characteristics of a user that is logged on the
R/3 system. It holds information needed by R/3 about the user, such as:
The users current settings
The users authorizations
The names of the programs the user is currently running
When a user logs on, a user context is allocated for that logon. When they log off, it is freed. It is used
during program processing, and its importance is described further in the following sections.
Understanding a Roll Area
A roll area is memory that is allocated by a work process for an instance of a program. It holds
information needed by R/3 about the programs execution, such as:
The values of the variables
The dynamic memory allocations
The current program pointer
Each time a user starts a program, a roll area is created for that instance of the program. If two users run
the same program at the same time, two roll areas will exist-one for each user. The roll area is freed
when the program ends.
NOTE
When speaking to a Basis consultant, you might hear the term roll area used to refer to all roll areas for
one user or even all roll areas on one application server. You usually can determine the intended
meaning from the context in which it is used.
Both the roll area and the user context play an important part in dialog step processing.
Understanding a Dialog Step
NOTE
A dialog step is used by Basis consultants as the unit of measure for system response time.
A dialog step is the processing needed to get from one screen to the next. It includes all processing that
occurs after the user issues a request, up to and including the processing needed to display the next
screen. For example, when the user clicks the Enter key on the Change Vendor: Initial Screen, he
initiates a dialog step and the hourglass appears, preventing further input. The sapmf02k program
retrieves the vendor information and displays it on the Change Vendor: Address screen, and the
hourglass disappears. This marks the end of the dialog step and the user is now able to make another
request.
There are four ways the user can initiate a dialog step. From the SAPGUI:
Press Enter.
Press a function key.
Click on a button on the screen.
Choose a menu item.
It is important for an ABAP/4 programmer to know about dialog steps because they form a discrete unit
of processing for an ABAP/4 program.
Understanding Roll-In/Roll-Out Processing
An ABAP/4 program only occupies a work process for one dialog step. At the beginning of the dialog
step, the roll area and user context are rolled in to the work process. At the end of the dialog step, they
are rolled out.
During the roll-in, pointers to the roll area and user context are populated in the work process. This
enables the work process to access the data in those areas and so perform processing for that user and
that program. Processing continues until the program sends a screen to the user. At that time, both
areas are rolled out. Roll-out invalidates the pointers and disassociates these areas from the work
process. That work process is now free to perform processing for other requests. The program is now
only occupying memory, and not consuming any CPU. The user is looking at the screen that was sent,
and will soon send another request.
When the next request is sent from the user to continue processing, the dispatcher allocates that
request to the first available work process. It can be the same or a different work process. The user
context and roll area for that program are again rolled in to the work process, and processing resumes
from the point at which it was left off. Processing continues until the next screen is shown, or until the
program terminates. If another screen is sent, the areas are again rolled out. When the program
terminates, the roll area is freed. The user context remains allocated until the user logs off.
In a system with many users running many programs, only a few of those programs will be active in
work processes at any one time. When they are not occupying a work process, they are rolled out to
extended memory and only occupy RAM. This conserves CPU and enables the R/3 system to achieve
high transaction throughput.
NOTE
ABAP/4 programs do not have the capability to intercept many common Windows events. The events
that generate a lot of messages such as key presses, focus changes, and mouse movements are not
passed to ABAP/4 programs. As a result, there is no way of performing some of the functions that are
found in other Windows programs. For example, in ABAP/4, you cannot validate the contents of a field
when the user presses the Tab key. You must instead wait until the user initiates a dialog step.
Discovering How the Data Is Sent to the Presentation Server
The messages exchanged between the presentation server and the application server are in an SAP
proprietary format. The SAPGUI accepts the screen information sent from the application server and
formats it appropriately for the platform it is running on. This enables different end-user hardware
platforms to connect to a single application server. For example, an OS/2 PC and a Windows PC can both
connect to the same application server at the same time.
Understanding the Components of a Work Process
Each work process is composed of the following:
A task handler
An ABAP/4 interpreter
A screen interpreter
A database interface
All requests pass through the task handler, which then funnels the request to the appropriate part of the
work process.
The interpreters interpret the ABAP/4 code. Notice that there are two interpreters: the ABAP/4
interpreter and the screen interpreter. There are actually two dialects of ABAP/4. One is the full-blown
ABAP/4 data processing language and the other is a very specialized screen processing language. Each is
processed by its own interpreter.
The database interface handles the job of communicating with the database.
Understanding the Types of Work Processes
There are seven types of work processes. Each handles a specific type of request. The type of work
processes and the types of requests that they handle are shown in Table 1.2.
Table 1.2 Types of Work Processes and the Types of Requests they Handle
WP Type Request Type
D (Dialog) Dialog requests
V (Update) Requests to update data in the
database
B (Background) Background jobs
S (Spool) Print spool requests
E (Enqueue) Logical lock requests
M (Message) Routes messages between
application servers within an
R/3 system
G (Gateway) Funnels messages into and out
of the R/3 system
Understanding the Logon Client
The term logon client has nothing to do with Client/Server-it is completely different.
The number entered here by the user corresponds to a set of rows within each client-dependent table
within the database.
Understanding Client-Dependent and Client-Independent Tables
There are two types of tables in an R/3 database: client-dependent and client-independent. A table is
client-dependent if the first field is of type CLNT. The length will always be 3, and by convention, this
field is always named mandt. If the first field is not of type CLNT, the table is client-independent.
This program selects rows from table lfa1 and writes out lfa1-lifnr. When this program is run, only two
rows are selected: only those where mandt equals 800. This happens automatically because the first
field in the table is of type CLNT. There are five rows in the table, but the program writes out only those
rows where mandt equals 800. If the user were to log on to client 700 and run the same program, three
rows of data would be found and written out. If the user were to log on to client 900, only one row of
data would be found.
The logon client mechanism divides the rows within a client-dependant table into distinct groups. To
access a different set of data, the user logs on and specifies a different client number.
NOTE
The user master records (containing R/3 user IDs) are client-dependent. Therefore, to gain access to a
client, the security administrator must create a new user ID for you within that client.
Developers and testers use the logon client mechanism to create and access multiple, independent sets
of data within a single table.
For example, assume two typical, asocial programmers are working on an enhancement to the billing
system. Jim is modifying the update transaction and Jane is creating a new report to go with Jims
modifications.
Jane sets up data for her test run, executes her report and obtains output. Jim works in the next cubicle,
but due to his antisocial tendencies is blissfully unaware that his transaction uses the same tables as
Janes report. He runs his transaction and updates the data. Jim got what he wanted, but Jane then
modifies her code and runs her program again. Her output differs from the last run, and the differences
many not result from her changes, but rather they may result from Jims changes. What we have here is
a failure to communicate.
If the tables used by Jim and Janes programs were client-dependent, they could each log in to separate
clients, set up independent sets of data, and test their programs without ever talking to each other.
They could perform all of their testing in the comfort of their cubicles and in isolation from their
coworkers.
To make their tables client-dependant, they only need mandt as the first field and the R/3 system will
take care of the rest. When records are added to the table, the system automatically moves the current
logon client into the mandt field when the record is send to the database. Their Open SQL select
statements will only return rows where the client number in the table is equal to the their current logon
client number. The Open SQL database statements insert, update, modify, and delete also provide
automatic client handling.
If the tables involved are all client-dependent, there can be more than one group of testers working at a
time in one test system. Two teams of testers can test divergent functionality in the same set of
programs at the same time provided they log on to different logon clients. The updates done by one
team will not change the data belonging to the other team.
A training client could also exist on the test system. The students could log on to one client and the
testers could log on to another. Both would run the same set of programs, but the programs would
access independent sets of data.
NOTE
The average R/3 installation has three systems: development, test, and production. By default, each
system comes with three clients installed: 000, 001, and 066. It is common to have from three to six
clients in the development and test systems, but rarely will you see more than one client in production.
- See more at: http://sapbrainsonline.com/cts-tutorial/change-and-transport-system-overview-bc-
cts.html



MATMAS01 IDOC TYPE Structure

Step by Step Approach for Configuration of Warehouse Management
By G.V.SHIVAKKUMAR
1. Concept of Warehouse Management
Master Data
Define control parameters for warehouse no
A warehouse number is an organizational unit in logistics that represents the company from the
warehouse management view.
In the Warehouse Management System (WMS), you can define various control parameters at the
warehouse number level. The control parameters will be:
1) Weights / units of measure
2) Storage unit management is active or not
3) Checking the data for capacity check

Define Number ranges
Define the number ranges for the objects which have automatic number assignment in the Warehouse
Management system. These are:
Transfer requirement
Transfer order
Quant
Posting change notice
Group
If you are using Storage Unit Management, you must take the following objects into account:
Number range for storage units
The number ranges for the storage units cover all the warehouse numbers.
Type of number assignment for storage units
Actions
1. Decide which number ranges you require for assigning the document numbers in the Warehouse
Management system.
2. Create the number range intervals.
The following action is only required if you are using Storage Unit Management:
3. Create the number range LE for assigning the storage unit numbers and the respective assignment
type (column VA). Via the assignment type, you can define per warehouse number whether, for example,
external or internal storage unit numbers are to be managed.
4. Conversion of the storage unit number in Warehouse Management, you can determine per client (!)
how the storage unit number is to be converted. For information on the different input options, refer to the
field documentation.

Define Storage Type
A warehouse number is divided up into a number of storage types. A storage type is defined on the
basis of its spatial or organizational features (for example, high rack storage area, bulk storage area,
and goods receipt area).
A storage type has the following features:
A storage type does not have an address, but a short description.
It is possible to store storage-type-specific material data.
Within a storage type, inventory is executed for each storage bin.
Recommendation
These interim storage types (900-999) are required for various postings (for example, GR and GI
postings, and differences) in WM. When you define your warehouse numbers, copy the interim storage
types from warehouse number 001.
Activities
1. Create your storage types with the respective descriptions.
2. Copy the interim storage types from warehouse number 001.
Important Note:
The placement strategy for ATC, AEC and ECO is decided as Addition to existing stock. So while creating
the storage type, the Put away strategy should be I Addition to existing stock.
The removal strategy for all the materials without Shelf life expiration date check (SLED) will be FIFI
(Picking strategy F) and for the materials with SLED check will be H Shelf life expiration date.
There will be two distinguished strategies one for materials without SLED check (Put away strategy I
and Picking strategy F) and one for material with SLED check (Put away strategy I and Picking
strategy H).
Define Storage Sections
Within a storage type, a storage section is a series of storage bins with the same features. These bins
are used for the purpose of stock placements.
For stock placements, the following features of storage bins can be important:
distance to the turnover point
loading capacity
temperature
Standard settings
In the SAP standard system, sample entries are preset for the respective storage types in warehouse
number 001.
Note
When you create a storage bin, you must enter a storage section.
If you are using storage types without sections, you must define at least one storage section (for
example, 001) per storage type. The storage section in this case is identical to the storage type.
Activities
Create your storage areas with the corresponding names.
Important Note:
There will be only one storage section for all ATC, AEC and ECO.

Define Storage Bins
Storage Bins
In the menu option "Storage bins", you define the configuration for the storage bins in the Warehouse
Management system.
Before you create the storage bins (master data) you should work through this section as well as the
section "Define field usage - Storage bin data".
Define Storage Bin Types
You can divide your storage bins into groups (for example, large storage bins, small storage bins, and so
on). A suitable storage bin is proposed by the system during stock placement in combination with the
storage unit type.
Actions
1. Decide whether you want to use the "Storage bin type search".
2. Create your bin types with the corresponding names.
Important Note:
Create only one Storage bin type for ATC, AEC and ECO.

Define Blocking Reasons
In the Warehouse Management system, you can block the following units for stock placements and stock
removals:
Storage types
Storage bins
Quants
Storage unit
You can enter the reason for the block (for example, assembly work) using the indicator "Blocking
Reason".
Actions
Create your blocking indicators with the respective descriptions.

Define Storage Bin Structure
In the Warehouse Management system, you can create a sequence of similar storage bins
automatically.
Example for setting up similar storage bins
Define the parameters required for creating storage bins in the table "Storage Bin Structures".
In this table, you must also define which warehouse master data (for example, storage section, fire-
containment section, and so on) you want to create when you generate the structures.
Actions
1. Create your storage bin structures in the detail screen.
2. From the menu bar (detail screen), select: "Environment --> Create bins" to generate your storage bins.
Note
This function can also be found in the application menu (menu option "Master data").

Material
In this menu option you configure the material master records that are relevant for the Warehouse
Management system.
Before you create the material masters, you should work through this section and the section "Define
field usage - Material master".
Define Storage Type Indicators
With this indicator you can control whether certain materials are placed into or removed from stock in
certain storage types with a higher priority. This leads to a classification of your materials and allows you
to use the stock placement or stock removal strategies in an optimum way.
Default settings
In the SAP standard system, examples are preset for warehouse numbers 001 and 002.
Actions
1. Classify your materials according to certain criteria (for example, small parts, and materials for
block storage).
2. Create your storage type indicators with the respective descriptions.
Further information
You will find more information on this subject area in chapter "Strategies - Storage type search"
Important Note:
Define 2 storage section indicators one for the materials with SLED check and one for the materials
without SLED check. In Storage type search you have to define the priority according to materials without
SLED check and materials with SLED check.

Define Storage Unit Types
With the indicator for the storage unit type, it is possible to distinguish pallets or other containers on which
a material is stored or transported.
The classification of your storage units allows you to use the stock placement strategies in an optimal
way.
The storage unit type is taken into account during stock placements if you have activated the "storage
bin type search".
Default settings
In the SAP standard system, examples are preset for warehouse numbers 001 and 002.
ACTIONS
1. Decide whether you want to use the storage bin type search.
2. Classify your storage units (for example, Europallets, wire boxes) according to certain criteria (for
example, certain packing height for Europallets).
3. Create your storage unit types with the respective descriptions/names.

Define Storage Section Indicators
The storage section indicator divides materials into groups with the same characteristics. With the
storage section indicator, you can assign certain material groups to special storage sections.
With this classification method, you can use the stock placement strategies in an optimum way.
Default settings
In the SAP standard system, examples are preset for warehouse numbers 001 and 002.
Actions
1. Decide whether you want to use "storage section search".
2. Classify your materials according to certain criteria (for example, fast-moving items, bulky
materials, extremely heavy materials, and so on).
3. Create your storage section indicators with the corresponding description.


Strategies
In the Warehouse Management system (LE-WM) you support strategies in order to receive proposals
from the SAP System
Regarding which storage bins the goods are to be put away
From which storage bins goods are to be picked.
There are two basic strategies in the system:
putaway strategies
picking strategies
With the help of these strategies, the SAP system can use the available transfer and warehouse capacity
optimally.
For each storage type, you must define a putaway and a picking strategy.
Recommendation
To be able to take a closer look at the processes involved in the storage bin search (that is, processes
that involve interaction between the materials master data and the data from the system configuration
menu in Warehouse Management), you can use the function "Log Bin Search".
You can call up this function from the preparation screens for stock placements and stock removals and
from the single item screen for creating transfer orders (menu option "Environment").
This bin search log supports, on the one hand, the work of the project team in the implementation phase
and, on the other hand, the analysis of customizing errors during productive operation.
Activate Storage Type Search
For putaway or pick operations, the Warehouse Management System (WMS) must know:
into which storage types materials can be placed
from which storage types materials can be removed
In the WMS, a storage type is determined as follows:
1. In the case of a put away, you generally know where the material for the put away is coming from. In
the case of a pick, you generally know to where the material to be removed is to be transferred.
Information on the location from where the material is to be picked is either stored in the transfer
requirement or determined by the system using the WM movement type.
2. The system must then know into which storage type the material should be placed, or from which
storage type the material should be removed. The table "Storage type search", which you are setting
here, provides this information. In this table, you store the preferred sequence of storage types to be
searched for the material for putaways or picks.
If you have activated the storage unit check, this check also influences the storage type search. In this
case, the storage unit type from the transfer order is also checked against the allowed storage units per
storage type. The system finds this information via the table "Allowed storage unit types / storage type",
which you are also setting here. For further information on this subject, refer to the chapter Storage type
search.
3. Furthermore, you can influence the storage type search using other indicators:
process indicator (for example, stock placement or removal)
storage type indicator from the material master
stock category indicator
special stock indicator
storage class
water pollution class (WPC)
reference movement type
The indicators storage class and water pollution class influence the storage type search. If you are not
implementing Hazardous Material Management, you do not need to pay attention to these parameters.
For information on how to activate Hazardous Material Management, refer to the chapter Hazardous
materials".
4. As mentioned above, different indicators influence the storage type search. If, however, you are using
storage type indicators and you also have materials with different stock categories or materials with
different special stocks, the number of required entries in the storage type search table can become quite
large.
To reduce the number of entries, you can define an access strategy for the storage type search table.
With the help of this access strategy, the system determines the required entries in the storage type
search table as follows:
The system first tries to find a suitable match, that is, an entry in the storage type search table
with all the relevant indicators from the material master and, if available, from the hazardous
material master.
If the system does not find a suitable entry in the storage type search table, it again tries to
read this table, but this time using the access strategy.
Actions
Set the required parameters for the "Storage type search" in the specified sequence:
1. Storage type indicator
Using the storage type indicator, you can ensure that certain materials are only removed from certain
storage types or placed into certain storage types in the order of preference you have defined.
You define the valid storage type indicators in the table for "Storage type indicators".
2. Storage type search
Now define the sequence of storage types to be searched by the system for stock putaway and stock pick
proposals.
Make sure that you enter the correct indicators for stock putaway and stock pick in the appropriate
column.
If you want the system to search through the entire warehouse number for a stock pick, enter "***" (stands
for stringent FIFO) as the storage type. The system will then search the entire warehouse for the oldest
stock of the material. The entry "+++" means that the system branches to the user exit to the stringent
FIFO process (MWMTO013).
If you are using the 2-step picking procedure, make sure that the destination storage type of the pick
step is used as the source storage type for distributing the accumulated quantities. For the storage type
search with the 2-step picking process, define activity type "2" (Column "Activity").
3. Movement type references
In the Warehouse Management component, you can set up the system so that for each WM movement
types certain storage types are proposed. If you want to use this mechanism, set up the necessary
reference movement types for the movement types concerned. These reference movement types must
be taken into account in the table "Storage type search".
4. Access optimization for storage type search
Instructions for access strategy for the storage type search table


Activate Storage Section Search
In the Warehouse Management System (WMS), a storage section is found in the following manner:
1. If the WMS is to search for a suitable storage section, it first searches for a suitable storage type. The
storage type is determined during the storage type search.
2. If the system has found a suitable storage type, it then determines the corresponding putaway strategy.
It finds this information in the "Storage type" table.
3. Now the system must "know" into which storage section the material is to be placed. The table
"Storage section search", which you are setting here, provides this information. This table contains a
preference list for the storage sections into which the materials should preferably be stored. The system
first searches for a bin in the first storage section. If it does not find a bin there, it continues its search in
the second section, and so on.
4. In addition, you can influence the storage section search using the following indicators:
storage section indicator from the material master
storage class
water pollution class (WPC)
Note: The WMS only takes the indicators "Storage class" and "Water pollution class" into account if
Hazardous Material Management has been activated.
To find out how to activate Hazardous Material management, refer to the section "Hazardous materials".
5. In the WMS, you can enter the storage bins for putaway manually. In this case, the system checks
whether the bin you have entered is in a storage section that is allowed for the material concerned.
Requirements
You must have the storage section check active. This check depends on the strategy you have chosen. It
can be implemented for all the putaway strategies, with the exception of the Fixed Bin Strategy.
Actions
Set the required parameters for the "Storage section check" in the sequence specified:
1. Storage section indicator
You can assign a storage section indicator to each material. This indicator enables you to have materials
placed into storage in special storage sections.
You define the valid storage section indicators in the corresponding table.
2. Storage section search
For each storage section indicator, you can have up to ten storage sections in one storage type. During
putaway, the system first looks for a bin in the first storage section; if it does not find a suitable bin here,
it goes on to the next section, and so on.
3. Activate the storage section search.




Activate Storage Bin Type Search
The Warehouse Management System (WMS) can manage different sizes of storage bins within a
storage type. The storage bins are determined during the storage bin search:
1. It is generally known which loading equipment (storage unit type) is required to place the material
into stock. This information is either
Entered manually OR
Can be found in the material master.
In this case, the SAP System suggests the relevant storage unit type for the putaway as a default.
2. Then the WMS checks if the storage unit which is to be placed into stock may be put away in the
storage typed determined by the storage type search.
The table "Allowed storage unit types per storage type" contains details on which storage unit types
(SUTs) may be used in which storage types.
This table defines which storage unit type may be used within each storage type. Up to 10 storage units
may be assigned per storage type.
If more than 10 storage units are required per storage type, it is possible to activate the weak SUT
check.
To do this, enter *** in this table as the allowed SUT. This has the effect that, in theory, all SUTs are
allowed for this storage type. The system then searches for a bin that matches the storage unit type
according to the allowed storage bin type per SUT.
3. Then the system searches for a suitable storage bin using the putaway strategy.
o For this purpose you have assigned a storage bin type to each storage bin in the master data.
o Via the table "Storage bin type search" the WMS finds information on which SUTs match which
storage bin types.
The search for a subsequent storage bin type is restricted to the permitted storage bin types
which are run through sequentially according to the sequence of entries in this table.
4. If you manually enter the storage bin during putaway, the WMS checks if the SUT may be used on the
relevant storage bin.
Requirements
The storage unit type check parameters must be activated. This check is independent of a particular
strategy. You can use it for all putaway strategies.
Recommendation
If you wish to implement the above weak SUT-check, check your table options exactly as performance
problems may arise if the customizing option is not properly set.
The following example should illustrate these problems and their solution:
Storage bin types P1 P2 P3 P4 P5 are allowed for storage unit type E1. E1 is to be placed in stock in
storage type 001. Here there are only storage bins of type P0.
Normally E1 would not be included in the storage unit types allowed for storage type 001. The WMS
recognizes this and searches for a bin in the next storage type.
A weak SUT check is when the database is accessed 5 times unsuccessfully. This number increases
depending on how many different storage sections you work with at one time.
You can check the Customizing options via the storage bin determination log (transport order
management). Multiple access to the database does not greatly impair performance. The number of times
the database is accessed in this way can be decreased using an optimized storage type search.
Activities
Set the parameters for bin type search in the following sequence:
1. Bin types
Divide your storage bins into groups (for example, large bins, small bins).
2. Check your warehouse master data and, if necessary, fill in any missing storage bin types.
3. Storage unit types
Classify your storage units (for example, by palette type).
4. Check your material masters and add palletization data, if this has not already been done.
5. Allocation of storage unit types / storage type
For each storage type, define which storage unit types may be placed into stock in this storage type.
6. Allocation of storage unit types / storage bin types
For each storage bin type, define which storage unit type may be put away.
7. Activate the storage unit type control function in the putaway control parameters for the desired
storage bin.






Putaway Strategies
The stock placement strategy is a procedure in the Warehouse Management system whereby the
system searches for a suitable storage bin within a storage type or a warehouse number using a
particular strategy.
The Warehouse Management system supports the following strategies:
Fixed storage bin
Open storage
Addition to existing stock
Empty storage bin
Pallets (storage units)
Bulk storage
Near to picking fixed bin
No strategy (manual bin location assignment)
Define Strategy for Fixed Bins
The "fixed bin" stock placement strategy is used for storage types in which a material is assigned to a
particular storage bin.
This strategy is used mainly in storage types where picking is carried out manually (for example, in small
parts storage areas with manual picking).
Default Settings
In the SAP standard system, warehouse number 001 and storage type 005 are preset for the strategy
"Fixed bin".
Actions
1. Decide whether or not you want to use this stock placement strategy.
2. If you have already created material masters, maintain the storage type data of the material masters
that is required for fixed bin management.
3. Enter the indicators for the stock placement strategy "Fixed bin" in the detail screen.

Define Strategy for Addition to Existing Stock
Using this stock placement strategy, the SAP System tries to place a quantity of material into a storage
bin in which the material already exists. To add to existing stock, there must be sufficient remaining
capacity in the storage bin. So you must switch on the capacity check for the relevant storage type to
implement the strategy addition to existing stock.
If the system does not find a storage bin with enough remaining capacity in this storage type, it will call up
the strategy "Empty storage bin".
Activities
1. Decide if you want to use this putaway strategy.
2. Decide which type of capacity check you want to use.
You can find out which capacity check types are currently supported via the possible entries field
capacity check.
1. Enter the indicator for the putaway strategy "addition to existing stock" in the detail screen.
2. Activate the capacity check.
Stock Removal Strategies
A picking strategy in the Warehouse Management System refers to a procedure whereby the system
searches during a pick for a suitable quant within a storage type or a warehouse number.
The Warehouse Management system supports the following picking strategies:
FIFO (First In First Out)
Strict FIFO
LIFO (Last In First Out)
Partial quantity
Large/small quantities
Define FIFO Strategy
With the stock removal strategy FIFO (First In First Out), the warehouse management system proposes
the oldest quant in each storage type from which you want to remove stock.
The system calculates the age of a quant using the date of the goods receipt posting that was set in the
quant by the transfer requirement and the transfer order.
Activities
1. Decide whether or not you want to use this stock removal strategy.
2. Activate the stock removal strategy "FIFO" in the stock removal control of the relevant storage type.

Define Strategy for Expiration Date
With this stock removal strategy, you can influence the search of the materials under consideration of the
shelf life.
Material managed according to shelf life expiration date is found as follows in the Warehouse
Management System
1. You must have activated the shelf life expiration date management in the respective warehouse
number.
2. For each storage type , the shelf life expiration date (SLED) strategy must be activated, providing
you do not work use the stock removal strategy "Strict FIFO principle".
3. The minimum remaining shelf life must be maintained in the material master record (storage view).
Materials for which this remaining life is not maintained are searched for with stock removal strategy
"FIFO".
Activities
1. You have to decide whether you want to use this stock removal strategy.
2. Activate the shelf life expiration date management for each warehouse number.
The shelf life expiration date management must be activated at warehouse number level. In the
application, this activation causes that the shelf life expiration date is a required entry during stock
placements, depending on the material and movement type. In some analyses, the shelf life expiration
date of materials managed according to shelf life expiration date is displayed instead of the GR date.
Activate the shelf life expiration date management.
3. Activate the stock removal strategy
Activate the stock removal strategy expiration date in the stock removal control for the relevant storage
type.
Further notes
If you are using the stock removal strategy "Strict FIFO principle", please refer to the section "Define
Strict FIFO Principle" strategy for more information on the "Shelf Life Expiration Date".


Activities
In this unit, you set the following activities in the Warehouse Management system:
Transfers
Differences
Print control
Physical inventory
Appointments
Define transaction parameters
Transfers
In this section, you set the configuration for the transfer of goods.
This includes the following:
1. Transfer types
2. Movement types
3. Requirement categories
4. Posting changes and stock transfers
Define Requirement Types
Movements and stock records in the Warehouse Management System contain a reference to the
originating document.
The requirement category describes the origin type (for example, goods receipt for a purchase
order, and goods issue for the cost center).
The requirement tracking number describes the origin itself (for example, the purchase order
number, the cost center).
Actions
Create the requirement types for each warehouse number.

Define Shipment Types
In the Warehouse Management system, there are two types of transfers (movements):
Movements that are also important for Materials Management
(for example, stock placements and stock removals)
Movements that only concern the warehouse
(stock transfers within a warehouse, for example).
The transfer type is a suitable tool for reports (for example, all stock placements into a storage type, all
stock removals from a storage type, and so on).
Note
The transfer type is not used in system control functions.
Standard Delivery
In the SAP standard delivery, all the relevant transfer types are preset.
SAP Recommendation
SAP recommends keeping the transfer types delivered with the standard system. You can add to these
transfer types as required.
Actions
Define the transfer types for each warehouse number.

Define Movement Types
The system processes Inventory Management movements (for example, goods receipt for a purchase
order or goods issue to a cost center) using movement types. If the SAP system determines that a
movement is relevant for Warehouse Management, it assigns a WM movement type to this movement via
a table.
The movement type for the Warehouse Management system provides the information required for stock
placements and stock removals:
Interim storage type
Coordinate of the interim storage bin
predefined coordinate
dynamic coordinate
fixed bin coordinate
Control indicator for processing, confirming and printing transfer orders
Indicator for storage type search.
For information on the links between the IM and the WM movement types and how to change them, see
the section Movement Types for Interim Storage Bins.
Standard settings
In the SAP standard system, all the relevant movement types are preset.
Recommendation
SAP recommends keeping the movement types delivered with the standard system.
Activities
1. Before you create movement types for a new warehouse number:
start with the configuration for the printer control
delete the print codes
then maintain the print codes when you configure the printer control
2. Create the movement types for each warehouse number using the copy function.
3. Define your own company-individual settings (for example, for the interim storage types) in the detail
screen.

Define Stock Transfers and Replenishment Control
Using a posting change, you can change the material identification of stocks. A posting change affects
at least one of the following items:
material number
plant
stock category
special stock
A stock transfer is involved if a quant is moved physically from its storage bin.
Posting changes and stock transfers always take place within a warehouse number.
Standard settings
For stock transfers and posting changes, the movement types in the series "3nn" are at your disposal.
For internal warehouse replenishment, use the WM movement type "319". You can use this movement
type as a copy sample for creating your own movement type.
Activities
1. Check all the movement types for posting changes, stock transfers, and replenishment.
2. Make your own company-required adjustments in the detail screen. For replenishment movement
types, you do not require the definition of the requirement type.
3. If you want to use the functionality "Replenishment for fixed bin warehouse" (using the report
RLLNACH1), you must define the storage types for which replenishment is to be used.
Assign the appropriate replenishment type to the respective storage types.



Confirmation
In this section, you configure the system settings for handling differences and for confirming transfer
orders.
Handling Differences
The system posts differences that you find in the warehouse into a specific difference storage type (for
example, 999) whenever you
Confirm a transfer order with differences.
Perform a manual stock transfer to the difference storage type (for example, 999).
Perform automatic stock transfer to the difference storage type (for example, 999) after an
inventory with quantity differences.
In the WM system, you can classify differences according to cause (for example, breakage, theft).
Using the difference indicator, you determine the storage type and the storage bin to which the
differences are posted.
For each difference indicator, you can save the percentage value for the deviation allowed, that is,
starting from which the dialog box is to appear. Suppressing the dialog box is appropriate for stock picks
that cannot be done to the exact amount and where the difference is cleared against the stock in the
source bin.
Example
A warehouse worker guesses a 3 kilogram pick for a particular material and determines the actual weight
further away from the bin. In this case, each pick is confirmed with a difference. It would be appropriate to
have the dialog box suppressed so as to save this extra step.
Confirmation Control
One important aspect of confirmation of transfer orders is the setting of the confirmation requirement.
This requirement means additional work for the user, but it also affords a high level of stock and
information security.
The decision as to whether a transfer order item requires confirmation and whether it is confirmed
immediately depends on the parameters you set for your movement types and your storage types.
At the warehouse number level you define:
o whether there is to be separate confirmation of pick and transfer
At the storage type level you define:
o whether putaways to this storage type require confirmation
o whether picks from this storage type require confirmation
o whether a zero stock check is to take place for a bin that becomes empty through the
pick
o whether the destination storage bin can be changed during confirmation
At the movement type level you define:
o whether transfer orders with this movement type can be confirmed immediately
o whether the confirmation requirement is to be proposed during transfer order generation
o whether single-step confirmation is to be applied although two-step confirmation is set for
the source and destination storage types
o through which screen the transfer orders are to be confirmed.
Confirmation Requirement
As soon as one of the above parameters calls for a confirmation requirement for a transfer order item, the
item must be confirmed.
Immediate confirmation of a transfer order item only works out if
the respective movement type does not disallow this
if the storage type from which the materials are picked is not subject to pick confirmation
if the storage type into which the materials are put away does not have a putaway confirmation
requirement.
Two-Step Confirmation
For two-step confirmation, both storage types involved in the transfer order must be subject to
confirmation.
At the warehouse number level, you define whether transfer orders or TO items are to be confirmed in
two separate steps.
During the confirmation of the first step, you confirm the pick process from the source storage bin. The
source storage bin and the quant are automatically updated. In the quant of the destination storage bin,
only the open transfer quantity is updated at this point.
During the confirmation of the second step, you confirm both the transfer process and also the receipt of
the material at the destination storage bin. Here the source storage bin and its quant are no longer
updated, but only the destination storage bin and the quant stored there.
SAP Recommendation
SAP recommends working with the stock placement and stock removal confirmation functions. The
confirmation procedure is recommended for the following reasons:
Stock in a storage bin should only be available after the actual putaway has been confirmed.
Storage bins should only be released for further putaways after the goods putaway in the
destination bin has been confirmed.
A storage bin that is going to be emptied by a pending stock pick should already be filled with a
putaway before it is really emptied.
The posting of differences should be executed during the actual confirmation, and not by means
of a separate transfer order.
Include the confirmation process in your organizational procedures.
You can use the bar code for confirming transfer orders. This makes your work much easier.
Activities
1. Decide whether you want to confirm the transfer orders created in the SAP system using the
confirmation procedure.
2. Maintain the difference indicator for differences in TO confirmation.
3. Maintain the indicator "Confirmation control/Warehouse number".
4. Maintain the indicator "Confirmation control/Storage type".
5. Maintain the indicator "Confirmation control/Movement type".





Define Print Control
In this section, you set the configuration data for print control.
Using the print control function, for example, you can define
Which documents (that is, for transfer orders) are to be printed for goods movements.
How these documents are to be printed (that is, which forms are to be used, how many copies
are to be printed).
On which printer a document is to be printed automatically.
Using the print control functions, you have flexible control of the printing activities in your warehouse. This
flexibility, however, means that setting the parameters is a complex task. For this reason, we recommend
that you take a look at the entire print control functions first, and then analyze the "print situation" in your
warehouse.
The number and type of settings you need for your print control depends on whether you are using the
Storage Unit Management component. If you are not using this component, you only need to set the
"standard" print control functions. However, if you are using Storage Unit Management, you need to set
both the "standard" print control functions as well as the functions for storage units.
In this section, we describe the "standard" print control functions. These control the printing of transfer
order slips.
The print control for printing specific slips for storage units is described in the chapter Define print
control for warehouses with Storage Unit Management.
You need the following settings for the "standard" print control function:
Spool Indicator
Slips are always printed within the SAP system using the Spool function. For each printout,
certain data needs to be passed on to the Spool file. Typical examples of such data are:
o Number of copies to be printed
o Dataset name of the printout within the Spool system
o "Print immediately"
o "Delete after print"
Using the Spool indicator, you define the most appropriate combinations of the individual
parameters you want to use.

In the following settings (for example, the settings for the print code), you do not need to specify
these parameters each time. You only enter the spool indicator as a type of abbreviation.
Printer Pool / Labels
In the printer pool for labels, you can define a dependent label printer for each printer. In this way,
for example, labels can be printed in parallel on special paper while transfer order documents are
being printed.
Sort Profile / Multiple Processing
The sort profile sets the sequence of the transfer order items for printing. As of Release 4.1A, this
only applies to printing in multiple processing, since during "standard" TO processing the sorting
is set already when the TO is created. Furthermore, you can decide during multiple processing
printing whether there should be a control break, that is, whether printing should continue on a
new page if the field content changes.
Print code
The print code defines the following information for printing transfer orders:
o Form that is used for printing
o Sort sequence (via sort pool) in which the individual items of a transfer order are to be
printed. The sort pool is now called up through the multiple processing run.
o Spool indicator (see above)
o Reading shipping data. With this function you can have additional information for picking
orders called up, for example, the address of the ship-to party or serial numbers already
assigned to the delivery items.
o Reading production data. Here reservations for staging materials for production are read.
(Both switches for reading data should be inactivated for time-critical printing.)
o Label form, label spool indicator, and the definition as to how the number of labels is to
be determined for each TO item.
The following text explains how you can assign a print code to each movement type in the
Warehouse Management system. A transfer order is always assigned to a movement type. In this
way, the print code determines the general print parameters for the transfer order.
Assignment of Print Code / Movement Type
You can define different printers and spool codes for various goods movements (source storage
type - destination storage type). Also, you can suppress the printing of transfer orders, if required.
There are also parameters (print code, form) that you can define both in the configuration
"Printer-Movement" as well as in the print code settings.
During the automatic determination of the print parameters, the system proceeds as follows: If an
item of a transfer order is to be printed automatically, the system determines the general print
parameters through the print code assigned to the movement type. Afterwards, it checks the
movement-specific print parameters. If one of these parameters (for example, for the form) is also
defined in the print code, the system will use the movement-specific parameter.
It is possible to override the definitions for label printing in the print code, depending on the
warehouse movement.
You can also store an additional form for a combined picking list with the spool code and the
printer in order to print a combined document in parallel to single printing for each TO item. This
is only possible as an accompaniment to non-combined-printouts (indicator for combined printing
in the print code) and is otherwise ignored.
Assignment Printer - Picking Area
It can be useful to select a printer near the picking area for printing picking orders.
Again you are faced with the question: How does the system proceed with automatic printer
determination, since it is possible to define a standard printer both in the configuration for
"Printer-Movement" as well as in the configurations "Printer - Storage Type", "Printer - Picking
Area", and in the user master of each user?
First the system checks whether a printer is set in the configuration "Printer-Movement". If so, the
printer determination is complete at this point.
If not, the system uses the parameter "PriSrcTyp" defined in the configuration "Printer-Movement"
to decide how it will proceed.
If the parameter is set here, the system checks if a printer is defined in the setting "Printer Picking
Area" and then proposes this printer.
If the system finds no printer, it searches in the setting "Printer - Storage Type" and uses this, if a
printer is set.
If the system cannot find a printer using the methods described above, it selects the printer
defined in the user master of the user currently logged on.
If no printer is defined here, the system automatically proposes LP01. This writes the data to the
spool file.
Assignment Printer - Storage Type
Here you can store one printer per storage type, in accordance with the printer determination
logic described above.
Assignment Print Code - Movement Type
A print code is assigned to each movement type. As described above, the general print
information is determined by this assignment.
Assignment Print Program - Warehouse Number
You must assign a print program to each warehouse number. The name of the standard program
is RLVSDR40.
Print Control Multiple Processing
A print report is assigned to each warehouse number for printing a
combined transfer order. You can also configure the following:
o the print code
o the printer
o the print time
The print layout is set using forms.
Standard settings
All relevant print control tables are defined in warehouse number 001.
The following print programs are available:
RLVSDR40 (general print program)
RLKOMM40 (multiple processing)
Recommendation
Only use your own print programs if your print requirements are not met by the user exits in the standard
system. If you wish to extend the functionality of the program RLVSDR40, use the user exit MWMD0001
to develop them. If you wish to extend the functionality of the program RLKOMM40, use the user exit
MWMD0002. For further information on enhancements through the user exit, refer to the chapter
Develop extensions.
Information on how to adapt forms in Warehouse Management is provided in the chapter Develop forms.
Further Recommendations
1. Before you begin with table maintenance, you should first look at all tables carefully and determine
which ones you need.
2. Then maintain the tables in the prescribed sequence.
Activities
1. Create the spool indicators for each warehouse number.
2. Create the dependent printers for label printing.
3. Define the sort profile for multiple processing.
4. Create the print codes for each warehouse number.
5. Assign the printers to the individual movements.
6. Assign the printers to the picking areas.
7. Assign the printers to the storage types.
8. Assign the print codes to the movement types.
9. Assign the print reports to the warehouse numbers.
10. Assign the print control to the multiple processing runs.
11. Using the analysis program, check whether the settings comply with your needs.

Physical Inventory
In this menu option, you configure the following system settings:
Default values
Types per storage type
Differences
Number ranges
Unlike the material-related physical inventory in the Inventory Management (IM) system, the Warehouse
Management system supports inventory procedures based on the storage bin.
Define Default Values
In this menu option you define:
which data should be printed out on the system inventory record
how the entry screen for the inventory count should be set up
Actions
Maintain the default values for each storage type.

Define Types per Storage Type
The Warehouse Management system (WM) supports the following inventory procedures:
Annual inventory(ST)
Counting the material quantity in the storage bins at a fixed inventory date.
Continuous inventory (PZ)
Counting a certain number of storage bins on any day in the fiscal year.
Continuous inventory based on stock placement
When a bin is occupied for the first time in the fiscal year, the system registers that inventory has
been taken for that bin. You can only use this inventory procedure under certain conditions and
must always check with the company auditor first.
Continuous inventory based on zero stock check
This procedure can be activated by the SAP system if a storage bin is empty.
Inventory through cycle counting
Counting of materials according to a pre-classification at different times during the fiscal year.
Requirements
You have coordinated your inventory procedure with the company auditor.
Actions
Maintain the inventory type for each storage type.

Define Differences and Document Limits
In order that the inventory differences can be posted to the interim record for differences, internal
movement types are required.
The movement types used for this purpose belong to the Warehouse Management area. The interim
record is determined by the system on the basis of these movement types.
Standard settings
In the SAP standard version, the following parameters are preset in warehouse number 001:
Inventory movement types
o 711 (Clear inventory difference)
o 712 (Post inventory difference)
Document items
o 50 (Items per system inventory record)
Recommendation
SAP recommends that you keep the preset movement types in order to avoid posting errors.
Activities
1. Posting/Clearing
Check the preset standard movement types and create -- if necessary -- special movement types for
inventory differences for your warehouse numbers.
2. Document items
If you make an entry in this field, you can restrict the system inventory records during their creation to a
particular number of items.
Clear Differences (Interface to Inventory
Management)
In this section you specify the movement types for posting differences in Inventory Management, and
specify from which storage types this type of posting can be started.
Movement type:
In order to be able to post inventory differences to the interim record for differences, internal
movement types are required.
The movement types used for this purpose come from the Inventory Management system, and refer to a
movement type in the Warehouse Management system.
The interim record for differences is determined on the basis of these movement types.
Prohibit storage types:
Technically speaking, you can post from practically all storage types. However, it is advisable to collect
the differences in one storage type (999) and start the postings from there.
Standard settings
In the SAP standard version, inventory movement types for Inventory Management are preset in
warehouse numbers *** and 001.
The settings for warehouse number *** are default values. If you require different parameters for a
warehouse number, you can add the difference movement types for the respective warehouse number.
The system first searches for an exact match for the table entry, that is, with the warehouse number. If it
does not find a corresponding entry, the system will search for warehouse number ***.
Recommendation
SAP recommends that you keep the preset movement types to avoid incorrect postings.
If you want to use the SAP standard system, you do not need to make new table entries for each
warehouse number. You can work with warehouse number ***.
SAP recommends setting this indicator for all storage types except the difference storage type
(999).
Activities
1. Analyze the entries for the default warehouse number *** and (if necessary) create the difference
movement types for your warehouse numbers.
2. Define your own company-individual settings for the movement types.



Maintain Number Ranges
In the menu option "Number ranges" you define number ranges for the inventory documents.
For each warehouse number you can create three number ranges:
for the system inventory records
Here the users create the documents themselves.
For transfer orders that initiate continuous inventory based on stock placement. In this case, the
transfer order is the inventory document.
for the quant-by-quant cycle counting physical inventory
SAP Recommendation
Once you have defined your number ranges, you cannot change them if the data in the number range
intervals has already been used.
Take the long-term data quantity into account. Define your number range intervals accordingly.
Actions
1. Define your number ranges.
2. Maintain your number ranges.

Questionnaire for Warehouse Management (WM) Module (for requirements understanding /
understanding clients business process)
By G.V.SHIVAKKUMAR
Project Title Questionnaier for WM Module
Conducted By xxxxx
Company: xxxxx Tel : xxxxxxxxxxx
Contact xxxxxx Desg :
Address: xxxxxx
Date: xxxxxx

Q1) List down storage location relevant for Warehouse Management

Ans:

Q2) Do you have storage locations, which are not relevant for Warehouse Management?

Ans:

Q3) Will you use storage locations for more than one plant? Name these storage locations and the relevant
plants.

Ans:

Q4) Describe the structure of your warehouse!

Ans:

Q5) Do you have warehouses with stock of different plants?

Ans:

Q6) List down Door define in the system?

Ans:

Q7) List down picking define in the system?

Ans:

Q8) Are you using external Warehouse control systems / subsystems? Do you plan to connect this system with
the R/3?

Ans:


Q9) Are you using bar-code / RFID system and interface with SAP?

Ans:

Q10) Are you using any external system determining the storage bins for stock placement / remove? If yes then
which system should determine the storage bins for stock placement / remove?


Q11) For removals and batch management, which system should determine the batch?

Ans:

Q12) Which system should generate the transport orders ?

Ans:

Q13) How does your automated storage and retrieval system communicate to the legacy system? Explain or
provide a design drawing.

Ans:

Q14) Are your using SUT management?

Ans:

Q15) Are pallets managed in the system with a unique number?

Ans:


Q16) Are pallets managed in the system with a unique number?

Ans:

Q17) Are materials posted to quality inspection after goods receipt, or are they in unrestricted-use stock?

Ans:

Q18) Can goods be issued directly from the goods receipt area?

Ans:

Q19) Do you post your materials to "blocked stock"?

Ans:

Q20) Do you post your materials to return delivery stock?

Ans:

Q21) Describe the individual steps from external goods receipt to final placement in storage (putaway).

Ans:
Q22) Do you have capacity limits for your storage bins, for example, weight, volume...?

Ans:


Q23) Is a transfer requirement is generating automatically at the time of a goods receipt with reference?

Ans:

Q24) For which goods movements are transfer orders to be created automatically?

Ans:

Q25) What kind of form (printout) are you taking for stock putaways (GR slip, transfer order form, sticker, etc.)?

Ans:

Q26) Is procured material pending inspection posted to stock or does it remain in the goods receipt storage
area? What happens with the samples: - Keep in GR area - post to stock - move to inspection area?

Explanation: Will procured material pending inspection be placed into permanent storage or remain in the
goods receipt storage area? What happens with the sample: - Keep in GR area - place into warehouse - move
to inspection area?

Ans:

Q27) Which parameters determine your putaway strategies?

Explanation: Storage type search

Ans:

Q28) Do you print the stock placement (putaway) document when the transfer order is created?

Ans:

Q29) Are transfer orders confirmed manually or automatically?

Ans:

Q30) Please list the storage types that have auto placement confirmation.

Ans:
Q31) Are you maintaining placement strategies (for example, storage types, storage sections, storage bins) for
your stock materials? If yes then what type of placement strategies are you using?

Ans:

Q32) How many storage bins do you have per storage type?

Ans:

Q33) How many stock putaways (items) do you have per day?

Ans:

Q34) Do you have consignment stock from vendors?

Ans:

Q35) Do you receive articles that have batch or serial numbers from vendors?

Ans:

Q36) Do you create a pre-allocation of your materials within warehouse management?

Ans:

Q37) Do you group together your pick list for multiple processing for a particular shipping point, route, pick
date, stock placement, stock removal?

Ans:

Q38) How do you handle stock differences that are noticed either at the time of transfer order confirmation or
continuous inventory based on bin-to-bin transfer?

Ans:

Q39) Are transfer orders confirmed separately or automatically by the system?

Ans:

Q40) How much time elapses between delivery of the goods and their inspection, and between inspection and
the arrival of the goods at their final destination? the destination bin.

Ans:


Q41) How are the picking results confirmed?

Ans:

Q42) Which documentation should accompany the goods that are returned to the vendor?

Ans:

Q43) Which documentation should accompany the goods that are returned to the vendor?

Ans:

Q44) Which movement types will you use for posting changes?

Ans:
[ ] Stock in quality inspection to unrestricted-use stock
[ ] Blocked stock to stock in quality inspection
[ ] Unrestricted-use stock to stock in quality inspection
[ ] Change in material number
[ ] Batch split
[ ] Consignment stock to own stock
[ ] Other


Q45) What type of documentation (forms) is to be generated in the case of transfer postings?

Ans:

Q46) Are you using any workflow to inform of a transfer posting?

Ans:

Q47) Do you use storage-bin-to-storage-bin stock transfers?

Ans:

Q48) Do you have warehouses with stock of different plants?

Ans:

Q49) Do you carry out complete pallet removals and subsequent return transfers? If so, to which location is the
merchandise returned?

Explanation: Withdrawal of whole pallet = requirement to remove all stock

Ans:
Q50) Will you maintain picking strategies?

Ans:

Q51) Are pallets managed in the system with a unique number?

Ans:

Q52) Is a transfer order is generating automatically at the time of a goods receipt with reference?

Ans:

Q53) For which goods movements are transfer orders are created automatically?

Ans:

Q54) What are the various user-exits that are used and for what purposes?

Ans:

Q55) What is the number of SAP Warehouse management users?

Ans:

Q56) What are the different outputs you use? Whether you use print out or email or fax or some other medium
to send the outputs?

Ans:

Q57) Do you have following documents?

Ans:
[ ] As-is To-Be document
[ ] Business blue print

[ ] User manual
[ ] Configuration documents
[ ] Test cases used for testing your system
[ ] Any other documents (Please specify)


Q58) Are you using any Work Around? (Please Specify)

Ans:


Q59) How many Z-Developments are their in your system? (Specify the T. codes & Use)

Ans:

Q60) Do you have any core team?

Ans:

Q61) Do you use interfaces to transfer data to or from SAP?

Ans:

You might also like