cancel
Showing results for 
Search instead for 
Did you mean: 

Influence putaway TO for inbound delivery before GR

former_member214692
Participant
0 Kudos

I need to generate a putaway TO for an inbound delivery linked to an STO. I need the material to go into a virtual storage type A01 -- can be ID Point storage type -- so that a subsequent LT09/LT10 step will transfer the material to its final destination B01 storage type.

If I were to do the MIGO_GR first, then I can easily accomplish this with use of special movement indicator. But because I'm creating the TO first (in background), I don't see any way to influence the putaway storage type search on the inbound delivery. Thus the system is putting it away into B01 storage type.

I can only think of using a BADI for the TO creation, or BADI to update inbound delivery with custom movement type (instead of 101). Is there any other solution?


Vlad

Accepted Solutions (1)

Accepted Solutions (1)

MANIS
Active Contributor
0 Kudos

Are you looking for two step confirmation ?

1st TO

902 ----- A01

2nd TO

A01 ----- HRS

if that is the case this can be very much simulated in standard SAP Did you tried using the concept of ID point what is your observation ? Have a look on the standard SAP link related to identification point

http://help.sap.com/saphelp_46c/helpdata/en/c6/f846aa4afa11d182b90000e829fbfe/content.htm

former_member214692
Participant
0 Kudos

ID Point won't work because I don't want to use it every time. For example, if I'm doing a bin to bin transfer into B01, or even direct GR into B01, then there is no need for the ID Point. I only would want the ID Point to get used for the 3PL STO scenario. But I can't point my putaway search strategy to use the ID Point storage type, since any reference to movement type for the STO GR can't be used...precisely because the GR comes AFTER the TO creation. That's why i was hoping to leverage the inbound delivery somehow.

2-step confirmation doesn't get me much either. I was really looking to isolating the stock into a virtual storage type (ie representing the stock on the 3PL's truck).

I may just live with an open TO into B01. But I can create separate queue using Door on inbound delivery. That way on RF menu the user can distinguish between STO putaway and other putaways.

MANIS
Active Contributor
0 Kudos

After analyzing more in detail i think you are right by doing some custom coding you will add more complexity however could you please suggest the reason for this specific requirement if your business allows to share

former_member214692
Participant
0 Kudos

I can share the business context.

The overall goal is for the 3PL to generate SU labels and affix them to the pallets/cartons being shipped to the plant. This is a significant labor savings vs. the plant doing the SU generation.

Because the 2-step STO process uses the 902 interim storage type (which cannot be SU managed), the SU gets lost on the GI side and then new SU gets created on the GR side.

Thus I have the 3PL generate the TO (followed by automatic GR posting) to create the SU. I would have liked that TO to go to a virtual storage type for more visibility that the item is not physically at the plant yet. But I can live with TO pointing to final destination storage type, since the Door on inbound delivery points the TO to a separate GR queue.

I don't suppose you are familiar with the Shipping config to default the Door into the inbound delivery? I haven't played with it, but it's unknown territory for me.

Vlad

philippe_marque
Active Participant
0 Kudos

Hi,

I would go for a separate IM storage location, linked to your warehouse. It would then be possible to have a separate WM movement type (hence a separate putaway strategy) through storage location control.

Philippe

former_member214692
Participant
0 Kudos

Philippe,

I'm not sure I follow. The 3PL is assigned to SLOC 3000 and the plant is SLOC 2000. Both on WM. As it is, I have an SLOC-to-SLOC STO. I would only want a single STO.

Vlad

philippe_marque
Active Participant
0 Kudos

hi,

Exemple:

3PL storage location = 3000

Plant storage location = 2000

Plant storage location for STO = 1000

You do your STO from 3000 to 1000.

You can define your special GR process with a special WM movement that goes from storage type 902 to A01.

Then you move the goods with LT09 into B01 and this will automatically do a transfer from storage location 1000 to storage location 2000.

When you do a purchasing for storage location 2000, hen you do a normal 902 -> B01.

Philippe

former_member214692
Participant
0 Kudos

This is a reasonable suggestion if I were using MIGO_GR and could specify movement type or reference indicator. But my issue is that I'm doing the Post GR function using the VL32N inbound delivery. What's more, the GR posting comes after the putaway TO generation, and secondly, it is automatically being posted  (since I see no point in the 3PL having to transaction both the TO and GR). That's why this circles back to my original question of influencing putaway TO from inbound delivery.

I should also add, for the benefit of others reading this thread, that using an interim 1000 storage type poses other challenges regarding MRP. I'm using MRP areas, and when I plan on 2000 I want to treat the 3PL in-transit stock as essentially available stock (it's literally minutes/hours away from inbound receipt). Using my inbound delivery STO process, the in-transit status achieves this nicely and stock is cleanly reportable in 2000 storage location. If the stock were residing in 1000, that would compromise MRP evaluation on 2000.


Anyway, I appreciate all the suggestions and will now close the thread.

Answers (0)