WM Structure

[Former Member]

Hi,

I'm at the beginning of WM implementation project and since my experience in this module is a bit shallow, I'm struggling to find out what's the best structure to implement.

So.. my client is logistic services provider and they manage the stocks for several clients. At one physical location they have 3 warehouses. There is a relation 1 warehouse, 1 client in two of the warehouses, but the third warehouse contains stocks for 5 clients. There are no transfers between the warehouses and, in this last warehouse, a given bin can be occupied by a client in one day, and in the next day it will be replaced by a material from another client.

I was thinking of having 3 warehouses numbers associated to 1 plant (representing the physical location). In the mixed warehouse, I was thinking of using the storage section concept to manage the clients. This means each area created will correspond to one client, and this way, I could know and manage, on any given time, the bins associated to one client.

What do you think of this structure?

Thanks in advance and regards,

Luís Silva

[csaba_szommer · Accepted solution]

Hi,

As I understand you want to map the physical structure of warehouses several times in the system correpsonding to the number of clients (you want to create separate torage types for clients --> if you have five clients the same bin will be in the system five times).

I'm not sure this is the right solution...so I would suggest you to forget this idea.

In my opinion you should have the same structure in the system as in reality (one bin in the system corresponds to one physical bin).

If the number of your client is not so many (I mean under 10), you should consider the use of several storage location - one storage location for each client. All the storage locations would be assigned to the same warehouse, and through the storage location you can identify and report which stock belongs to which client.

If the number of client is high or clients change continuously, this concept is not the best I think.

You can also solve the problem if you can make difference between the goods. I mean e.g. if you use batch number or characteristics to identify to which client the goods belong. (E.g.

material; batch

material1; client1

material1; client2).

In this case you're likely to have to do some development.

You can also use the quant to store some information on the client - development is needed in this case.

You should also consider the use of one warehouse number instead of three - in this case you can use the storage types to make difference between warehouses. Of course, this should be decided based on the business requirements.

I gave my suggestion w/o knowing the exact requirement (e.g. I don't know whether the bins are hired by clients or they pay only for the storage of the goods - concept might be different...)

Regards,

Csaba

[Former Member · Accepted solution]

Hi,

Thanks for answering.

You understood me wrong and I think I didn't explain my ideia very correctly, sorry.

In my conception of the structure, each physical bin will only be represented by just one bin in the system, there will be no duplication of the physical bins in the system.

The clients will be charged by the space (and time) occupied in the warehouse, so I need to know which bins they have been occupying. And like I said, in the warehouse where there are multiple clients, a bin can be occupied with a material from a client in one day, and in the next day change to a material from another client.

Since we can assign a bin to a storage section in a easy and fast way, the idea here was to create a storage section for each client and assign the bins that a client is currently occupying to the respective storage section that represents that client. This way we could easily know which bins are currently being occupied by a given client. Does this makes sense to you?

Regarding your sugestion of the storage locations, I mentioned 5 clients in the mixed warehouse, but it can grow. And since we also going to use HUs, we would need two storage locations for each client.. doesn't seem the best solution for this particular scenario.

The idea to differentiate the goods was having a material type for each client and to use the number range concatenated with the storage section. I mean e.g. Client1 is represented by storage section C01, all goods from this client will have the material number starting with C01, like C0100001; C0100002, etc.

I've seen someone else suggesting the same as you, having just one warehouse number instead of 3, and having 3 storage types representing the 3 physical warehouses, but don't really know what are the advantages of this.

The idea for the 3 warehouse numbers was just to keep things separated and isolated, since like I said in the previous post, there will be no transfers between the warehouses, so each material will only have the WM view of one warehouse and each client will only be using one warehouse. Can you tell me what are the advantages of using the storage types instead of having 3 warehouse numbers?

Thanks once more for the answer.

Best regards,

Luis Silva

[Former Member · Accepted solution]

Hi,

I have few thought process on your scenario. Please consider these points if it really helps.

As Csaba had pointed out the first preference of differentiating the client stocks ( Third warehouse ) could be better at Storage location level ( As you said it would be not possible for you to define more number of SLOC's)

In that case why dont you can create one warehouse for one client. The advantage is that the Warehouse monitor objects are at WHN level and you will be able to clearly demarcate the different client stocks very easily. ( It your client quanity is keep on increasing then it would not suffice your requirement )

The third option is maintaining a relation ship between your storage type and client ( one Storage type for one client ) but how ever if you want to have multiple putaway strategies for your client ( n number of strategies for one client ) then this idea could be absurd.

The last and final solution would be differentiating with respect to Storage section. But i would not suggest this process as tracking the client level stock at Storage section level will be quite complicated and confusing. Also if your volume of bins is quite high then this idea needs to be discarded.

Please consider these points if it really suits your requirments and ignore if the conditions prevailing at your project contradicts my assumptions.

Thanks and Regards,

[Former Member · Accepted solution]

Hi,

thanks for answering, nice to have other inputs

Having one warehouse number for each client, would mean, in the case of the mixed warehouse, duplicated bins, since clients will share bins (not in simultaneous but in different periods of time) , e.g if I have 5 clients, one physical bin will be in the system five times.. that doesn't sound very good.

I don't yet know how many putaway strategies I will have for each client, but I'm assuming I will have more than one or at least I want to leave that possibility open for the future.

Regarding storage section solution, why do you say that tracking the client stocks will be complicated and if the volume of bins is high the idea needs to be discarded?

Threw LX03 tcode, I could easily check, given a warehouse number and a storage section, which bins are assigned to that section (even the ones that are empty), the stocks levels, etc.

Thanks and regards,

Luis Silva

[Former Member · Accepted solution]

Hi Luis Silva,

I understand that you have different materials for each client. No Materials are comman for clients.

Having said, Your option of creating a St. section for a client is OK.

But the problem is A storage bin will have only 1 storage section and cannot have 5 storage sections at a time.

You should change the storage section name of all bins daily by a batch job. but this is possible only if all bins are emptied at the end of every day. In your case is it happenning so? If so, your solution is OK. Otherwise you have to exclude the occupied bins from batch job for the next day.

I have one more solution.

You can create 5 st. types instead. Then you can create all bins (say 100 bins) in each st. type with same Nomencleature.

Here is the difference. You can have a bin under 5 st. types but not with 5 st. sections. Here the advantage is you need not change st. sections daily. You can see the status of st. type & understand the situation.

Futhermore, it is similar to your solution different sections, but here, C01 is st. type. material number starting with C01, like C0100001; C0100002, etc.

Create a storage type Indicator for each Client. Give this in corresponding Materials. It could be a permenant solution.

As Dill babu Radhakrishna was mentionong about different strategies for different clients, Yes it will not work. but even with storage sections also you cannot serve this purpose.

So, conclusion is either seperate warehouse for client or seperate st. type for client

Regarding your 3 warehouses, I hope what you are doing is correct.

Best regards,

Nagesh

Edited by: Nageshwar Rao on Oct 21, 2009 7:44 PM

[Former Member · Accepted solution]

Hi Nagesh,

But the problem is A storage bin will have only 1 storage section and cannot have 5 storage sections at a time. You should change the storage section name of all bins daily by a batch job

This is not a problem for me, each bin will only have to be associated to a section (in my case, meaning a client) at a time. And I will only have to change the section of a bin when, for instance, client1 has sent some goods and the bins reserved for client1 are full, so I will go to the bins of client2 that are empty and changed the section of those bins to the section corresponding to client1.

I have one more solution.
You can create 5 st. types instead. Then you can create all bins (say 100 bins) in each st. type with same Nomencleature.

This solution implicates the replication of the bins in the system, meaning 1 physical bin will correspond to 5 (if I have 5 clients) bins in the system..doesn't sound to good. Don't know yet the exact number but the number of bins will be something like 3000. 3000*the number of clients will give a huge number..

many thanks and regards,

Luis Silva

[csaba_szommer · Accepted solution]

Hi,

1WH vs 3WH

I think the advantage of having only one WH numer is configuration, master data maintenance. Disadvantage is that stocks can be posted to improper storage type/bin; other thing might be maintenance of search strategies.

(my opinion)

Duplicated storage bins:

I do not suggest any scenario in which there are fictive bins.

Business requirement:

I think there's no solution for this in standard system and I don't like storage section idea.

I think you should go to development. You could add "Z" fields to data table LAGP - e.g. customer number; from date; to date. You can create new transaction for reporting and maintenance.

I try to avoid developments if I can.

But in your case the storage section solution wouldn't mean standard solution since I think you should develop reports and maintenance transaction. Other disadvantage is that storage section maintanance is configuration

So, in my opinion you should consider development...

Regards,

Csaba.

Edited by: Csaba Szommer on Oct 21, 2009 6:10 PM

[Former Member · Accepted solution]

Hi all,

Thanks for all the inputs. I think I've now the info I needed to advance.

Points have been awarded

Best regards,

Luís Silva