Non-Available for Sale Storage Location for Returns

[petrzak]

The principle of available and non-available storage location is quite useful and helps to organize outbound activities and to monitor on time shipments more precisely. Especially at complex warehouses, where put away takes longer time, or when you need to check the incoming goods and still don’t want to use quality stock.

Typically we use external procurement or production storage location in material master to determine the non-available sloc. For returns we might use the stock type of the customer returns, which is non-available stock type, there are however more type of returns. Apart from returns to sales order, we also have returns for consignment, replenishment or returns for lent inventory. Especially the lent inventory need some preliminary checks and is not immediately available for another rental. Sales order returned inventory is also considered to be still owned by customer and explicitly uses only 651 movement type, this is not applicable to equipment which is rented out and returned for example.

So for return deliveries we can activate Advanced Returns Management and in case we are free to create new Sales Order types for our returns, this is definitely preferred solution. We can specify storage location for returns into unrestricted stock with reason code and to use standard customizing. When you create return delivery with reference to the original one, system however uses the original storage location in the standard scenario.

In case we want to drive returns using different item category with appropriate schedule line movement type, which seems to be elegant solution, we quickly find that the storage location determination works in the same way like for the outbound process, you can choose from determination by shipping point or determination by situation or combination of both, or to use the user exit. The configurable options are limited, because the customer shipping conditions, storage conditions, plant and shipping point are the same.

Another option is also to use auto-putaway and auto-confirmation of putaway and to link the destination storage type through availability group with different sloc. That however also does not seem to be the right solution.

When having a look on storage location determination rules, the rule MALA is quite clear and simple, but you can see however there is nothing about returns. It gives us one storage location for one shipping point (let’s say we are not changing material master RAUBE just to do a return).

SELECT SINGLE * FROM TVKOL WHERE VSTEL = IVSTEL

AND WERKS = IWERKS

AND RAUBE = IRAUBE.

IF SY-SUBRC = 0.

ELGORT = TVKOL-LGORT.

ENDIF.

 

Storage location determination rule RETA should be more promising, there are however 2 drawbacks. At first there is no shipping point in the table TWLOF, which reduces applicability of this solution to only 1 shipping point per plant (we can have entries in TVKOL for the others). But more importantly the difference between inbound/outbound is done per document type as you can see in the code of FM SD_STORAGE_LOCATION_DETERMINE:

IF NOT ILAGOF-EALKZ IS INITIAL.

IF ILAGOF-EALKZ = 'E' AND ILAGOF-SITUA(1) = '0'.

ILAGOF-SITUA(1) = '1'.

ELSEIF ILAGOF-EALKZ = 'A' AND ILAGOF-SITUA(1) = '0'.

ILAGOF-SITUA(1) = '2'.

ENDIF.

ENDIF.

 

The standard ECC logic says the inbound situation (ILAGOF-EALKZ = E) happens only for document category (VBTYP) “7 - Delivery/shipping notification” or “g - Rough Goods Receipt (only IS-Retail)”. These are inbound deliveries. Unfortunately this no logic for delivery types (VBTYP) of returns (H). So it seems the scenario for returns is missing in this program. In case we are creating document with reference and LGORT is already given, the whole logic is just skipped. The return scenarios for VBTYP = H are all hidden in the Advanced Returns Management.

As you can see from EWM point of view, we don’t have many options how to make returns simply non-available for picking. More naturally the inbound/outbound movement could be determined simply by the debit/credit indicator on movement type and during the delivery creation we know the movement type from schedule line table VBEP. So as an alternative to the Advanced Returns Management we can use the user exit EXIT_SAPLV02V_002, which is available in the configuration and to insert the logic for situation determination based on the movement type.

Since TWLOF table does not include shipping point, the ideal solution seems to be to utilize fields in TVKOL of the Advance Returns Management, which can be switched on, but you don’t need to activate any document. For outbound movements (T156-SHKZG = H) you can use TVKOL-LGORT and for inbound (T156-SHKZG = S) TVKOL-MSR_RCV. Just keep in mind in case we are working with cancellations and the storage location is given by the reference document, we need to skip this logic as well, to keep the system consistent.