We are facing serious problem in our Storage Location for Raw Material.
We have 4 types of Raw Material Seating (S), Panel (P), Metal (M), Wood (W). And they are all stored under Storage Location: RWSL.
Although we have visual guideline as to which industrial rack will store the type of Material, it is insufficient. We need a more refined storage location down to which BIN of the rack we will put the Raw Material.
Due to limited time and resource, we cannot have WM implemented right now. Thus, we have come out with 2 alternative to overcome this problem:
We will use the Fixed Bin field in Storage Data 02 by putting the Bin number assigned to each Rack.
E.g. For Seating material code:SEAT01, we will maintain the Fixed Bin as R12A01/A02, it means this Seating material SEAT01 will be stored at Rack 12, fixed bin A01 or A02.
Question to Alternative 01: Will it cause problem in GR, GR, Transfer Posting and Stock Count?
Instead of going into details to put Fixed Bin field in Storage Data 2, we will abandan the existing Storage Location RMSL by introducing new format for Storage Location
Here is the example of Alternative 02:
For raw materials, we will use 4 digits location numbers, consistent with other Storage locations, the 4 digits storage location will start with u201CR _ _ _u201D to represent each location
R _ _ _ is:
R = Raw materials
2nd digit = Division (S= Seating, P =Panel, W=Wood, M=Metal and W=Wood)
3rd digit = Rack Number (A, B, C, Du2026 and etc.)
4th digit = Rack Zone - each rack will broken down into zone, each rack can possibility have 2 to 3 zone. 1 Zone can be 1 colume of the Rack
An example of a possible location and its meaning will be
RSA1 = Raw materials warehouse, Seating division, Rack A, Zone 1
RPB3 = Raw materials warehouse, Panel Division, Rack B, Zone 3
The challenge of this is that instead of having 1 Raw Material Storage Location like RMSL, we will have a lot more storage locations each for division of Raw material due to the Rack Number we have as well as the Rack Zone.
Question to Alternative 02:
If we use this alternative, will it impact our future implementation of WM? From design wise, is it feasible?
Please advise what is the best approach and the feasible design on it.
Many thanks in advance.
Edited by: Daimos on May 13, 2009 10:15 AM
alternative one is not suggestible.if there are no wm settings like ware hose and its assignment to storage location to that plant, storage types etc, this alternative will not work.Unless there are no settings for WM putting in the material master with the details will not work.WM itself is a mdule.If you want we can post the details.
alternative 2.Though how best is the naming convension, it is nothing but creation of new storage locations in the system.Once you post stock into them they will be under operation.At later date if you want to go for WM, this leads to transfer postings (this will be depend upon number of warehoues you want to define. and in WM each ware house will be assigned to the storage location of that plant).
But ofcourse alternative 2 though not suggestible but suits.may not be the best/good.
But you need to take lot more care during implementation wm due to number of storage locations.
There are number of steps involved in wm.First you need to createa a ware house.
This ware house has to be assined to the storage location which you feel to have with wm features of racks, bins etc.
Then you need to define the storage types, storage sactions, bins etc for that ware house.
You need to define storage storage strategies.like during the moments where to place the stock or pick the stock etc.
You have to define wm moemnts to get mapped with mm momemts.
You can check at SPRO--Logistics execution you will get all the confif needed.
Hi, here is the Pro and Co of both approaches:
Method 01: Use existing SLOC and add the Storage Bin info
e.g. SLOC: STM1
Storage Bin: RSC3, where RS = Rack Seating, C3 = column 3
It will cause less effort as we only need to use LSMW for material master to add in the Storage Bin data for all material of SCM.
I have tested out that in TCode MIGO, apart from SLOC, the pertaining Storage Bin data also appear. Based on my discuss with Xian Chen, sometimes they use MB1C(GR), MB1A(GI) rather than MIGO due to speed issue, I will need to check the field status if can have Storage Bin field APPEAR, if can, it will solve the problem
The Storage Bin information will only appear in MMBE (Stock Overview) but will not appear in the standard SAP Inventory Report (e.g. MB52 Warehouse Stock). To view it from SAP Inventory Report, we may need to customize the standard report to show the new field Storage Bin. It needs Abap effort.
We must have a very good naming convention for Storage Bin. And again, in the above example, if a material is put in SLOC STM1 at Storage Bin RA A1 or C4, it will set a very rigid rule in the future if we need to change it, as I fear that one the Storage Bin has been used up. It will not allow us to change (need to do testing to find out)
Do we have the time to define all the Storage Bin for each SLOC? Operation wise, the store personnel needs to design it
Method 02: Use the new SLOC
RSA1 = Raw materials warehouse, Seating division, Rack A, Zone 1. More organized. Easy to tell the material is at which Rack and which Zone of the Rack.
01. we must not have too many rack for one Seating division and also not too many Zone for each
Division, else it will cause confusion
02. 1 material should stick to 1 Rack 1 zone as much as possible, else later the PP consultant will
have hard to to perform GI due to too many SLOC assigned to a material.
In report wise, we are able to show the SLOC in inventory report. No need to enhance the existing inventory report as we do not use Storage Bin.
If there are too many SLOC creation due to it. It may cause problem for PP perform GI as too many selection available for a material. This can be avoided if stick to the General Rule that one material is tied with one SLOC.
Edited by: Daimos on May 16, 2009 5:07 AM
Need effort to convert the SLOC for all materials into the new SLOC naming convention especially those used in SCM. Need to do SLOC to SLOC transfer posting and some other necessary step to allow this to take place (need to research)
In the future, if we are using WM, it will involve a reengineer of another new SLOC to fit the WM and the existing new naming convention of Method 2 be abandoned.
Given the fact we have time and resource contraint, what is the best approach?
Sorry have to post through reply else all the wordings will be cramped together.
Edited by: Daimos on May 17, 2009 4:12 PM