100%(2)100% menganggap dokumen ini bermanfaat (2 suara)
475 tayangan62 halaman
The document describes the architecture of SAP R/3, which is based on a three-tier client/server model consisting of presentation servers, application servers, and database servers. The presentation server displays the user interface. The application server interprets ABAP/4 programs and manages input/output. The database server accepts requests from the application server and retrieves data from the database.
The document describes the architecture of SAP R/3, which is based on a three-tier client/server model consisting of presentation servers, application servers, and database servers. The presentation server displays the user interface. The application server interprets ABAP/4 programs and manages input/output. The database server accepts requests from the application server and retrieves data from the database.
The document describes the architecture of SAP R/3, which is based on a three-tier client/server model consisting of presentation servers, application servers, and database servers. The presentation server displays the user interface. The application server interprets ABAP/4 programs and manages input/output. The database server accepts requests from the application server and retrieves data from the database.
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?