How are storage location locations associated to storage type

[Former Member]

Hi ,

I have a question ,

Incase of a storage location ROD , it takes only stock of F1 type which is unrestricted use in putaway . why is that.
For AFS , similarly it uses F2 type of stock which is unrestricted use in Warehouse.

How can these two things be linked. Tell me what storage type will suit ROD and what will suit AFS.
I can understand a bit, when it comes to ROD , the picking is not possible as the goods are jus in dock , received , so that it cant be
directly used for picking in case if it has process like DE-consolidation, VAS ,etc.

That s why a concept of cross docking was introduced.Similarly stock types like Q1,B1,Q2,B2,IM would fall under which storage location and why. Please some one brief me to understand this concept easily. I would be so thankful to you.    

Regards,
Anandakiran Thilak.

[Former Member]

Hi Juergen ,

Good morning.

Thank you so much for the reply . It was of great help. Appreciated.

When any product is in the GR area , corresponding stock type is F1 say for the availability group 001. Similarly when the product reaches the final destination bin , the availability group is changed to 002 and corresponding stock type F2.

Can we say that the main work of the availability group is to reflect the changes that happens in EWM  to reflect in ERP..?

How does this function happen. How are storage type, warehouse process type, stock type associated with availability group.

You also mentioned that when the goods are in GR area , the movement of the goods cant be tracked in the ERP side where as it can be monitored only using MMBE unless it reaches its final dest bin , where the stock type is again to F2 based on the availability group of storage bin.

Please brief me some basic functions of availability group. I can refer materials but when it comes to discussion it is even more easier to understand.

Regards,

Anandakiran.

[JuergenPitz]

Hi,

ok, a short version:

EWM does not know storage locations (this is due to that EWM is based on a SCM Basis, which does not know that, here you only have the LIME (Logistics Inventory Management Engine), which knows stock types. But of course we need to know the owner (Plant and storage location) of the stock in EWM.

The connection is:

Plant + Storage location + Logical System  = availability group in a warehouse number

Warehouse number + availability group + location independent stock type = stock type

Location independent stock type is the general stock categorization, like unrestricted, blocked, quality inspection, returns.

Which availability group you have in inbound, is coming from ERP with the inbound delivery (because there you have a plant and storage location).

In the ROD / AFS scenario the change from one storage location to the other is triggered by the mandatory requirement of the stock to be in a certain availability group in the final storage bin (the field availability group and the flag "mandatory" in the storage type).

Brgds

Juergen

---

Want to learn EWM?

Check for EWM courses: https://training.sap.com/curriculum/scm_ewm

Get a SAP Learning Hub Subscription: https://training.sap.com/shop/learninghub

[Former Member]

Hi Juergen

I have a simple requirement.

If my inbound delivery says one storage location, I would like to have the stocks into the same storage location ever after final bin WT confirmation.

(I have four storage locations attached to one single warehouse)

For my outbound delivery all four are valid locations.

How, can we set this?

Thank you in advance.

Srinivas

[JuergenPitz]

Nah, come on, that can not be difficult!

What did I wrote?

"In the ROD / AFS scenario the change from one storage location to the other is triggered by the mandatory requirement of the stock to be in a certain availability group in the final storage bin (the field availability group and the flag "mandatory" in the storage type)."

So all you do is NOT to enter any availability group in the storage type and NOT to flag the field "Mandatory".

Brgds

Juergen

[Former Member]

Thank you Juergen for your quick response.

Ultimately I have understood the concept of 'availability group' in EWM. I am good here now.

But, I have some other queries hope, you thoughts would be helpful on this.

I have a HU managed sloc (for example HU01) which is now also EWM managed along with another non-HU managed sloc (for example SL01).

When I do a transfer posting in MIGO, for a quantity of material (for example MAT1 which is a new material created after EWM assignment) from SL01 to HU01, I am seeing an error VL296 - HU cannot be delivrd from plant XXXX stor. loc. SL01 to plant XXXX stor. loc HU01

Would you please help me if I am wrong any where here.

My primary question here is 'Can I go for a EWM for already HU-managed storage locations'?

Thanks in advance.

[former_member193471]

Hello Srinivas,

No, you should not assign EWM WH for storage location which has stock. Before you assign warehouse, you move the stock out and bring the stock back to EWM assigned storage location.

Right now, you do stock upload using /scwm/isu in EWM for the matching stock details of ECC with out sending interface back to ERP. or, increase the stock using Physical Inventory in EWM again stopping queue.

Once you make stock balance in both system, then, you can do stock transfer across the storage location. you do this in ECC,if both WHs does not get assigned to same WH.

Regards,

Sathish

[JuergenPitz]

Hi Srinivas,

asside from the point Sathish brought up, you are missing one other basic thing.

"I have a HU managed sloc (for example HU01) which is now also EWM managed"

You can not have a HU managed sloc together with a decentral warehouse number. That does not work. Depending on the sequence of setting it up, the ERP system does not come up with an error message during setup, but you will get the problem at least with the first stock posting.

If you try it in the "correct" sequence (you first setup your warehouse number as decentral and then you try to activate the sloc with HU requirement), you will get the following error:

Ah, now I see that at the end of your question you also directly asked this. So, to answer your primary question: no, you can't.

Brgds

Juergen

[Former Member]

Thank you so much Juergen for your detailed explanation as usual .

Meanwhile, I too came to know what you said, by trying all three possible ways of such assignments. (a. assign a sloc to EWM warehouse; then try to convert it to HU managed -> error; b. assign a HU sloc to EWM warehouse -> error; c. assign a HU sloc to WM warehouse, then convert it to distributed warehouse -> success); Last case made me confused.

I request your thoughts again for another query which is on the same lines. Here, it is...

HUs maintained in EWM system for inbound deliveries are reflecting back to ECC inbound deliveries upon GR posting against that inbound delivery. Similarly the same is true for outbound delivery order HUs and are reflecting back to ECC outbound delivery upon PGI for that ODO. etc..

When I run HUMO, system will reflect HUs which are in sync with EWM HU details for above two cases.

After putting away the HUs into physical bin for a inbound delivery, if I moved them to another storage type where stock type and hence availability group is something different with mandatory indicator. (for example PSA location 1000 with 003 availability group with mandatory set)

In this case, when this internal WT is confirmed [which can also be created with reference to a stock transfer warehouse request (for example using /n/SCWM/IM_ST)], system also posts a posting change WT to change the stock type inline with destination storage type and triggers a 411 mvt to ECC against this posting change WT, to cause the sloc to sloc movement in ECC.

But, this HU movement across the storage locations will not be reflected back to ECC system because this movement is not referenced to any delivery document to carry HU details.

Now, if I run HUMO, I can see mismatches in HU storage locations.

Queries on the above scenarios:

1) Can we execute EWM internal transfers so that it will also generates a delivery to carry HU details to ECC system along with 411 stock movement wherever is applicable so that HU locations in both the systems will be in sync.

    - I have tried assigning delivery type DTR to SHWI etc but did not generate any delivery

2) If I assume, for all EWM managed storage locations HU management in ECC system is not relevant, then why some of the HUs (like HUs which are linked with ID and ODO) are being reflected to ECC and maintaining a track of HU history.

Bit elongated, please excuse me.

Thank you

Srinivas

[JuergenPitz]

Hi,

"1) Can we execute EWM internal transfers so that it will also generates a delivery to carry HU details to ECC system along with 411 stock movement wherever is applicable so that HU locations in both the systems will be in sync."

No way I know of. The HU is not sloc relevant. It only shows the inbound delivery it came with. Also in ERP in such a scenario you would not know any posting change, as long as the sloc is not HU managed.

"2) If I assume, for all EWM managed storage locations HU management in ECC system is not relevant, then why some of the HUs (like HUs which are linked with ID and ODO) are being reflected to ECC and maintaining a track of HU history."

The HU in ERP simply does reflect the most actual assignement. But does it matter? Why look into HUMO at all if you have no HU requirement on sloc level? That is the answer.

Brgds

Juergen

[Former Member]

Thank you Juergen for your apt answer.

If system would not have been updating the VEKP and VEPO tables for EWM HUs only for inbound and outbound deliveries, I might not have had this confusion.

Thank you again.

advanced happy new year.

[JuergenPitz]

Hi,

first of all: if you plan to use cross-docking, you do not use ROD and AFS as storage locations. Because it does not make any sense. And a storage location is not really linked to a storage type.

What is the usage of ROD and AFS? They are for what is called "storage location scenario" in WM. What does that mean? Imagine you have WM. You post the GR, in that moment the material does exist as quant in the GR area. Now the material is available (assuming you have no QM), so you can create a sales order, an outbound delivery, and warehouse task - and then you run into a problem. Because the GR zone is usually NOT part of you picking storage type search sequence. Or the material is on the way from the GR zone into the the warehouse, and is not available (from a warehouse perspective. And assuming you have no other stock in the warehouse).

That why you can work with the storage location scenario. You order the material for the ROD storage location. ROD stands for "Received on Dock". That is where you post the GR to. Then you move the material with a WT (or in the case of WM with a TO). And when the material arrives at the final storage bin, the system makes a posting change into the storage type AFS (=Available for sales). Now the real trick is that when you create an outbound delivery in ERP, this makes a "picking storage location determination" - and in here you ONLY find the AFS storage location. So as long as the material is still in the GR zone or on the way to the final bin in the warehouse, it is "not available" for ERP. It is available if you look into MMBE, but you will not be able to create a delivery (assuming you make a "proper" availability check).

In EWM additionaly you do not have storage locations, but stock types. And the storage locations are connected to the stock types via availability groups.

When you putaway the material in the final bin, the storage type for this bin has a flag that the material has to belong to the availability group which is connected to the storage location AFS. Thats why the system makes the posting change.

If this whole szenario is not interesting for you (means you do not really have the problem that material gets sold before it is in the final bin, or you do cross docking, or the process of creating warehouse tasks for picking anyway happens later, after you have putaway your material) - you do not use anything of this. All you need is one storage location, one availability group, and the stock types to reflect the different stock qualificiations - unrestricted, blocked, quality inspection and returns.

Brgds

Juergen

[Former Member]

Hi Juergen,

                      I have a scenario where we have 4-5 storage locations which are single warehouse managed.For each storage locations created seperate Availability Group and Stock type.But there are different GR-Zones for each storage locations.But currently we have only one Process type for GR-Zone .Do we need to have 5 process types defined for different GR-zone for each location.Is there a way we can handle this only one Process type.

Thanks,

Kris

[JuergenPitz]

Hi Kris,

having different process types could be one way to determine different staging areas, but the question is how do you determine the process type for each storage location? This is not part of the standard determination.

The staging area which is in the process type is like the "standard" staging area. You can also have a complex staging area and door determination, this then superseeds the staging area from the process type. But also this determination in the standard does not include a determination triggered with the help of the storage location or a stock type. There is a Badi available for the determination, so here you can include this.

And from a gut feeling I thing I would rather use this Badi and expand the staging area / door determination and not have more process types when necessary.

Brgds

Juergen

[Former Member]

Hi Juergen,

                   Thanks for the Reply.I have tried to find the proper BADI,but couldnt find it.Can you please send the BADI details.

Thanks,

Kris