User Exits for TO Processing
With this customer exit, you can influence how many pallets are to be used during stock placement of a material.
General information about transfer order processing
Transfer order processing and confirmation in the WM system are divided into the
- SAPML03T Screens, transactions
- SAPLL03A Item creation (TO core)
- SAPLL03B Function modules for external purposes
- 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.
- "TB" Transfer order for transfer requirement
- "LF" Transfer order for delivery note
- "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'.
- "IV" Clear inventory
- "U1" Create first item for posting change
- "U2" Create second item for posting change
- "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:
- " " Normal transfer order item
- "1" Quant-neutral stock removal that requires verification of storage units during the confirmation process
- "2" Storage unit verified during confirmation
Items with item type "1" are deleted as soon as confirmation is complete.
How to call up the customer exit, important requirements
The customer exit takes place on the preparation screen for stock
placement, before the first item is created. The palletization data from the material master is proposed and can be changed. Also, it is possible to propose workitems for creating the transfer order and to change the storage type indicator for the stock placement.
Only A or S messages can be sent.
Parameters and options
The customer exit in the program is FB EXIT_SAPML03T_002. To fill it with data, you must create Include ZXLTOU13 and activate the customer exit using Transaction CMOD.
The following parameters are available:
- I_LTAK the respective TO header from which, for example, reference documents such as the TB number are derived.
- I_LTAP TO item
You can obtain further information on filled fields in I_LTAK and
I_LTAP from the interface documentation of the function module L_TO_PREPARE_ITEM_INT.
- I_MLVS Material master
- I_MGEF Hazardous material master
- I_T333 Movement type with which the TO is created
- I_T340D Warehouse number control
- I_VORGA Procedure within TO processing
- I_EINML Total quantity to be placed into stock in base unit of measure
- C_LTKZE Storage type indicator for stock placement
- C_ANZL1 Number of storage units of storage unit type 1
- C_LETY1 Storage unit type 1
- C_LMEN1 Quantity per SUT 1 (alternative)
- C_LMEL1 Quantity per SUT 1 in base unit of measure
- C_LGTY1 Destination storage type for SUT 1
- C_LGBE1 Destination storage area for SUT 1
- C_ANZL2 Number of storage units of storage unit type 2
- C_LETY2 Storage unit type 2
- C_LMEN2 Quantity per SUT 2 (alternative)
- C_LMEL2 Quantity per SUT 2 in base unit of measure
- C_LGTY2 Destination storage type for SUT 2
- C_LGBE2 Destination storage area for SUT 2
- T_LTAPE Table of workitems for stock placement
There are no export parameters. The C parameters as well as Table
T_LTAPE are passed on by reference and can be changed directly. If you have your own workitems, it is important that the required quantity is filled both in base unit of measure as well as in alternative unit of measure (fields T_LTAPE-ANFML and T_LTAPE-ANFME). The fields
T_LTAPE-XTAPS and T_LTAPE-TAPOS must have initial value. If the pallets are changed,it is important to change the quantity per SUT in base unit of measure as well as the quantity per SUT in alternative unit of measure. The units of measure and the conversion factors can
be taken from I_LTAP. The total that results from the palletization and the workitem cannot exceed the quantity to be placed into stock (I_EINML).
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: CALL FUNCTION 'L_TO_CREATE_GET_INFO' EXPORTING I_LAGP_COPY = 'X' I_LQUA_COPY = 'X'
I_LTAP_VB_COPY = 'X' TABLES T_PSPERR = PSPERR T_LSPERR = LSPERR T_QSPERR = QSPERR T_SSPERR = SSPERR T_TAP = TAP
T_BDBATCH = IBDBATCH.
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_SAPML03T_002: Palettization and Storage Type Determination for Putaway