Given storage unit removal from FIFO storage type

[former_member631463]

Hi Friends,

We have issues with the pallet removal from "Open" storage type which have removal strategy "F"(FIFO). The required pallet ID (SU no.) supplied from the initial screen of custom RF transaction for plant to plant stock transfer (303 and 305 movement in IM). Material document for stock removal gets created correctly also the TR. But when it comes to TO creation system selects different SU than the supplied one in initial screen.

We've tried to use the user exit MWMTO004 and MWMTO013 to suggest the required SU number, but didn't get successful result.

May I have your input on:

1) Is it possible to amend SU selection thru' these user exits?

2) Can we have ability to suggest different SU than system selected?

Regards,

Sudhir

[Former Member · Accepted solution]

The way I have tackled this in the past is to use the putaway strategy, "Bulk" or "Block" storage, which basically allows you to pick and scan any SU and this then gets updated into the Transfer Order. This obviously doesn't follow a strict FIFO policy, but there is a function in the IMG when you set this strategy up to llimit the putaway into a particular lane as shown below to maintain a FIFO strategy.

Number of days after the first transfer to the row (storage bin) after

which no goods can be transferred into the row.

The date of the first transfer to the row is used as the goods receipt

date of all subsequent transfers to the row. Therefore, it is a good

idea to stop other transfers to the row after a certain number of days

so that the FIFO principle is not violated.

[former_member631463]

resolved.

[Former Member]

Hi Sudhir,

It's definitely possible to change the SU selections in the exit. You must use MWMTO004 with FM EXIT_SAPLL03A_005 (include ZXLTOU07). In here you can have code to change the selection, for example:

===================================================================================================

CASE i_t331-staus.

WHEN 'F'.

• FIFO stock removal strategy - T_QMAT should already be filled

SORT t_qmat STABLE ASCENDING BY vfdat.

WHEN ' '.

• No strategy - Fill T_QMAT

• Fill ranges

PERFORM zxltou07_fill_ranges USING i_ltap i_mlvs.

• Select data

SELECT * FROM lqua INTO TABLE t_qmat

WHERE lgnum = i_ltap-lgnum

AND matnr = i_ltap-matnr

AND lgtyp = i_ltap-vltyp

AND werks = i_ltap-werks

AND lgort = i_ltap-lgort

AND bestq = i_ltap-bestq

AND charg IN r_charg

AND sobkz IN r_sobkz

AND sonum IN r_sonum

AND skzua <> $x "User Removal Block

AND skzse <> $x "Current placement

AND skzsa <> $x "Current removal

AND skzsi <> $x. "Current inventory

IF i_ltap-posty = 1.

SORT t_qmat BY lgtyp wdatu lgpla.

ELSE.

SORT t_qmat BY lgtyp wdatu lqnum.

ENDIF.

SORT t_qmat STABLE ASCENDING BY vfdat.

WHEN OTHERS.

==================================================================================================

Try using removal strategy " " as well, as seen from the code above.

I hope this helps.

Cheers,

Hein

[former_member631463]

Thanks friends for the valuable input. The cause for this issue found in immediate TO creation. We managed to ammend this field's value thru' exit and restricted the TO creation. Then convert the TR into TO thru' std function module by passing the supplied SU no. to LENUM/VLENR. This resolved the issue.

Thanks

Regards,

Sudhir

[Former Member]

The way I have tackled this in the past is to use the putaway strategy, "Bulk" or "Block" storage, which basically allows you to pick and scan any SU and this then gets updated into the Transfer Order. This obviously doesn't follow a strict FIFO policy, but there is a function in the IMG when you set this strategy up to llimit the putaway into a particular lane as shown below to maintain a FIFO strategy.

Number of days after the first transfer to the row (storage bin) after

which no goods can be transferred into the row.

The date of the first transfer to the row is used as the goods receipt

date of all subsequent transfers to the row. Therefore, it is a good

idea to stop other transfers to the row after a certain number of days

so that the FIFO principle is not violated.

[former_member631463]

Hi Mark,

Thx for reply. I also used the same earlier but in current situation it is not possible to implement that way.

Actualy if I use single step plant to plant stock transfer (301 movement) thru' custom program; it pickes correct SU no. which supplied in initial screen of program. But when it comes to 303 movement (stock removal from plant) system misses the supplied SU and picked it's own SU as per FIFO.

The difference between these two movement have setting with TR generation in 303 and PCN in 301. Unable to understand how this differance have effect on changing supplied SU. Also observe one thing thru' debugging that when custom code runs BAPI_GOODSMVT_CREATE, it creates TR as per customising and converts it immediately to TO. During this TR to TO conversion we could not find the line where we can pass the SU number supplied earlier in the TO creation.

If any body have inputs on this will be great help..

Sudhir