General information about transfer order processing

Transfer order processing and confirmation in the WM system are divided into the following programs:

1. SAPML03T Screens, transactions
2. SAPLL03A Item creation (TO core)
3. SAPLL03B Function modules for external purposes
4. SAPLL03T Update tasks

These four programs work together as follows:

SAPML03T contains all the transfer order processing screens. All related transactions are initiated using screens from this program. All corresponding data is read, checked and recorded here (transportation requirements in transfer order: transportation requirements, transfer order: confirmation, etc.)

Actual creation or confirmation of items occurs via function modules in SAPLL03A , where the transfer orders are first created and recorded internally as the putaway and picking strategies and several checks are run. Changes in storage location, storage unit or stock that may arise from individual transfer order items are simulated in internal tables.
Item creation and confirmation occurs in two steps. First, the item is generated internally and all checks are carried out. Then, the internal tables are updated via a second function module and the transfer order items are added internally. You can view this two-step process by running transfer order creation in the foreground (screen SAPML03T 102). First, the system generates the transfer order item, then issues a warning. If entries are made on the screen, the system regenerates the transfer order item (including all checks) and the previous one is discarded. The internal tables are updated after the warning disappears.
The confirmation process follows a similar procedure.

User action 'post' in SAPML03T is carried out after an item is created or confirmed, which in turn calls up function module SAPLL03A , which then activates the update function modules in SAPLL03T. These function modules are normally processed asynchronously (supplement IN UPDATE TASK), but can also occur synchronously (see below). All changes in storage location, storage unit, stock, transportation requirements or transfer orders are made in these function modules.

SAPLL03B contains function modules for creating and confirming transfer orders which can be used instead of transactions. First, the normal screen run of the parameters transmitted is reviewed. Reading, checking and recording of the data and part of the flow logic occurs via external performs in SAPML03T and in a common data area, to avoid redundant code. Item creation and confirmation takes place in function modules found in SAPLL03A.
Function modules L_TO_CREATE_TR and L_TO_CREATE_DN, for example, are used in collective processing in the SAP standard system. Updating occurs synchronously in this case.

Transactions in SAPLL03A and SAPML03T

Some checks within the transfer order creation and confirmation processes depend on the transaction concerned. This transaction (field VORGA) is placed at the disposal of all user exits so that the system can react as required for the transaction involved.

Relevant values:

1. "TB" Transfer order for transfer requirement
2. "LF" Transfer order for delivery note
3. "TL" Transfer complete storage unit

Homogeneous storage units can also be transferred explicitly. In this case, the value of the field is LTAP-HOMVE = 'X'.

1. "IV" Clear inventory
2. "U1" Create first item for posting change
3. "U2" Create second item for posting change
4. "QB" Confirm storage unit for stock removal from SU-managed block storage area

Within the SU-managed block storage ares, the item type (POSTY) of a TO item is of interest. It is set when the source data is determined and can have the following values:

1. " " Normal transfer order item
2. "1" Quant-neutral stock removal that requires verification of storage units during the confirmation process
3. "2" Storage unit verified during confirmation

Items with item type "1" are deleted as soon as confirmation is complete.

Call transactions and relationships

This modification consists of four user exits in SAPLL03A. The respective function modules are EXIT_SAPLL03A_005 through EXIT_SAPLL03A_008. In addition to the activation in transaction SMOD, you have to select the stock removal strategy in the storage type control (stock removal strategy '1'). In order to explain the meaning of the individual function modules, the stock removal strategy FIFO is used as an example.
The function modules have the following meaning:

Function module EXIT_SAPLL03A_005 is called up in order to find appropriate stocks for a given storage type. In contrast to the stock placement strategy, this module does not find a storage bin, but sets up and sorts a table (T_QMAT) of the stocks of a material in a storage type. If the material is changed, Table T_QMAT is refreshed, but with regard to contents this table belongs to the user exit and must also be updated by the exit (see EXIT_SAPLL03A_007 and EXIT_SAPLL03A_008). This user exit can be combined with the stock removal strategies " " and "F". If the stock removal strategy is " ", the exit operates as described above. If the stock removal strategy is "F", SAPLL03A sets up the table T_QMAT so that the user exit only needs to execute the sort. This table is set up (directly before EXIT_SAPLL03A_005 is called up) whenever the storage type has not yet been imported into table T_QMAT, that is, if there is no entry KZTYP = 'X' in T_QMAT for this material and storage type. The structure of table T_QMAT is compared with respect to the database stock with the TO items that have already been generated internally. Items generated internally by other users are not taken into consideration.

Example FIFO:
The requested quantity is 30 pieces, available in stock are 60 pieces at 5 locations. The first call the function module creates table T_QMAT and sorts it according to GR date:

No storage bin needs to be blocked. All other actions are taken over by the source bin quant determination in the standard system. If, for example, storage bin 01-02-03 is currently blocked for physical inventory, storage bin 03-05-06 is used. Users that are simultaneously working with this material are considered by the standard system.
During the second call, the requested quantity is reduced to 18 pieces. Table T_QMAT still exists and does not need to be set up again, that is, the function module does not need to do anything.

Note: If you want to make a negative posting at one storage bin, it is important that the entry in question has a positive available quantity in table T_QMAT because entries without available quantity are not considered for reasons of performance.
Abend messages and system messages can be issued directly whereas warning messages and error messages must not be issued. If no stocks are found, an empty table T_QMAT should be returned to continue the search in the next storage type.

• Function module EXIT_SAPLL03A_006 is called in order to check a stock that is generally given by the user. This function module is not called if function module EXIT_SAPLL03A_005 was performed directly before, that is, entries that originate directly from table T_QMAT are no longer checked. Because of the division in the TO creation described above, it is still possible that a stock is determined and proposed to the user. If some interaction is performed on the screen now, the items are created again. If you cancel the proposed storage bin, function module EXIT_SAPLL03A_005 is performed. If you confirm or overwrite the storage bin, this definite storage bin is checked with function module EXIT_SAPLL03A_006. Abend messages and system messages may be issued directly whereas warning messages and error messages must be issued via the interface (see below).
  This function module is not relevant for the FIFO example, that is, the respective Include could remain empty.
• Function module EXIT_SAPLL03A_007 is called if the TO item in question is created internally, for example, to update your own internal tables. (Second part of the item creation). No error messages may be issued here.
  For the FIFO example, this would mean that during a withdrawal of 12 pieces from storage bin 03-05-06 the available quantity for this entry in table T_QMAT is set to 0. If this is not updated, the system would try again to make a withdrawal from this storage bin. The availability check for this storage bin (which requires positive stocks) would reject this withdrawal and may continue with storage bin 06-01-02. Thus, nothing 'wrong' would happen but consume performance.
• Function module EXIT_SAPLL03A_008 is called if the TO item in question is deleted internally, for example, to update your own internal tables or cancel updates with function module EXIT_SAPLL03A_007. No error messages may be issued here.
  For the FIFO example, this would mean that the withdrawal of 12 pieces from storage bin 03-05-06 must be reversed by increasing the available quantity in table T_QMAT by 12.

Parameters and options of the individual function modules

EXIT_SAPLL03A_005: Setting up and sorting the stocks of a material

In order to be able to use the function module, you must create Include ZXLTOU07.
The following parameters are available:

Import parameters

1. I_LTAK The respective TO header that contains, for example, the reference documents such as the transfer requirement number or the like.
2. I_LTAP The TO item that has been created so far

Please refer to the interface documentation of function module L_TO_PREPARE_ITEM_INT for more information on the filled fields I_LTAK and I_LTAP.

1. I_MLVS Material master
2. I_MGEF Hazardous material master
3. I_T331 Control data of the storage type from which the withdrawal is to be made
4. I_T333 Movement type with which the TO is created
5. I_T340D Warehouse number control
6. I_ANFML (Remaining) requested quantity in base unit of measure. This quantity is relevant if the active ingredient processing is not active (I_LTAP-WIRME is set to initial value).
7. I_VORGA Transaction within the TO processing (see above)

Table parameters

1. T_QMAT Table with bin stock to be filled with data and/or sorted
2. T_BDBATCH Table of the batches found by the system via the search parameters

The following note applies only to batch determination via the batch search procedure (I_T340D-CHSWM or I_T333-CHSWM) for materials that are handled in batches (I_MLVS-XCHPF) and do not have a pre-specified batch in the TO item (I_LTAP-CHARG):
Table T_BDBATCH contains the batches found by the search procedure. Table T_QMAT contains (if already filled by the system) only stock for batches from T_BDBATCH. Entries for batches that are not included in T_BDBATCH are ignored in subsequent processing after the user exit.

There are no export parameters.

Information on the status of transfer order processing

Using the function module L_TO_CREATE_GET_INFO you can obtain information on the current status of transfer order processing. In addition to Table TAP with the transfer order items already created, you can use the following tables: PSPERR, LSPERR, QSPERR and SSPERR. These tables contain the storage bins, storage units and quants affected by the transfer order. However, the contents of the more important fields do not match the status in the database. Instead, they appear as if the transfer order items created up to now have been posted. The update of the item currently being posted is not included in the table.

If, for example, a bin is read in the user exit, we recommend that you have the system first check in Table PSPERR and then, only if data access is unsuccessful, to read the database. If this is not possible (for example, the bin is read by the index for empty bins), a bin that has been read should still be compared with Table PSPERR.

The only exception to this rule is a quant affected by blocking logic B. In this case, QSPERR has the status that would exist on the basis of the current transfer order. Changes that arise from parallel transfer orders are only partially included. If, for example, transfer orders 1 and 2 (in this sequence) access the same quant and the respective items have already been created internally, QSPERR contains the stock of transfer order 1 minus the current item and for transfer order 2 the stock is minus both items. Therefore, to have the current stock in each case, the database stocks must be compared with the global blocking table (blocking object ELLQUAY via function module "ENQUEUE_READ" read and evaluate). Whether or not this exact stock reading is required should be decided in each individual case.

The following example of a stock removal via user exit may be of help in making this decision:

Bin stock database: 10 pieces
TO 1 removes 5 pcs and first creates the item internally
TO 2 wants to have 10 pcs removed from stock.

The user exit also decides on this bin. The quant is not in the internal table because no internal item yet exists. Irrespective of whether the user exit proposes the bin with a stock of 5 pcs or 10 pcs, transfer order 2 (providing there is a positive stock balance) would at most take 5 pieces and would try to supply the remaining 5 pieces by means of a further item. Within the user exit, the correct stock is not important for the stock removal to be "correct". It is only important if it affects a decision, that is, if the user exit proposes another bin because only 5 pieces could be removed from the first bin.

Table IBDBATCH is available for you to create your own stock removal strategy. This table is important for batch-neutral documents if you want your own stock removal strategy to be influenced by the standard batch search function.

All the above tables are predefined for the user exit. If the system is to access one of these tables within the user exit, the current version must be called up via the function module L_TO_CREATE_GET_INFO. The following example shows you how to call up Tables PSPERR, QSPERR and TAP. The other two tables are not of importance because there is no SU management involved:

The table parameters must always be specified; only the marked tables (with "X") are copied.

Table IBDBATCH can only be called up by user exits from SAPLL03A. Otherwise the content is undefined.

EXIT_SAPLL03A_006: Checking a given source storage bin

In order to be able to use the function module, you must create Include ZXLTOU06.
The description of the parameters basically corresponds to the description of function module EXIT_SAPLL03A_005. Below, only the differences are described.

Import parameters

1. I_LTAP The TO item that has been created so far, except that source storage bin, source storage unit and source quant are filled now (I_LTAP-VLPLA, I_LTAP-VLENR and I_LTAP-VLQNR)
2. I_T331 Control data of the storage type of the storage bin that is checked
3. I_MANPL Manual storage bin default. If I_MANPL = 'X', a given storage bin is to be checked manually, if I_MANPL = ' ', the stock was proposed within a strategy involving several storage types (strict FIFO principle).

Table parameters

1. T_QMAT Table of the bin inventories (depending on the call sequence, it may be empty!)

Export parameters

1. E_SUBRC Processing return code with the following values
1. R_CUS_OK => Use checked storage bin
2. R_CUS_EXIT => Do not use checked storage bin
3. R_CUS_WARNING => Use checked storage bin and send a warning message
4. R_CUS_ERROR => Do not use the checked storage bin and send an error message
2. E_MSGID Message ID for the error message
3. E_MSGNO Number of the error message
4. E_MSGV1 First variable in the error message
5. E_MSGV2 Second variable in the error message
6. E_MSGV3 Third variable in the error message
7. E_MSGV4 Fourth variable in the error message

If you enter the storage bin manually (I_MANPL = 'X'), an error message or warning message should be processed, if necessary. In the case of a
Function/Program:

• EXIT_SAPLL03A_005: Internal Stock Removal Strategy: Determine and Sort Stocks
• EXIT_SAPLL03A_006: Internal Stock Removal Strategy: Check Default Bin
• EXIT_SAPLL03A_007: Internal Stock Removal Strategy: Update Internal Tables of New Items
• EXIT_SAPLL03A_008: Internal Stock Removal Strategy: Update Internal Tables of Deleted Items