Problem with SUT into bin type table

[Former Member]

When in SPRO in strategy -storage unit type search strategy - SUT in bin type table,we have only 30 entries possible.
BUt we need more somewhere like 150 records because of a bulk storage type with a lot of storage bins with different
size and therefore capacity. To define true exact capacity we need different bin types right?
I am not sure how to do this,maybe there is a option in settings to change 30 to 150 or 200 to make the table bigger?
Or any other solution will be great because we do need this because in the way it works now,we have a lot of problems
in putaway,we have huge realocations since we have not exact capacities but we had to group bins with similar capacity
but that means that three bins with 48, 52 and 56 capactiy all have 52.

[mihailo_sundic · Accepted solution]

If I remember correctly this has been asked numerous times before, try searching the discussions.

Anyway, you have a couple of possible solutions for this.
It is understandable that you don't want hundreds of reallocation on daily basis, and you don't want to lose the capacity otherwise, but it feels that your bins should and could have been planned a bit better, there is always a way to unify capacities, split bins, use the storage space in a more meaningful manner. This is the point where your optimization was supposed to be done, not in SAP. But anyway, you are stuck with what you have and here are the solutions that cross my mind.

1. Standard SAP:
Split the bins to multiple storage types, this way you will have 30 bin types, but they will have different capacity for different storage types (in OMM4). Easy and standard, but has the downside that you will have to manipulate with 5 storage types instead of 1. A bit of more customizing but will solve the problem. Also, storage type search will need to be changed to include all the STs... Might be harder to track the strategies but this is the only standard way that crosses my mind.

2. ABAP:
This is the solution I have used and works fine, though you will need an ABAP-er to complete this.
Create a z-table/view having the same structure as the standard one, just add 120 more fields.
Well, not only that, you will have to change the coding to use this custom table instead of standard one, and although this isn't the brightest solution since you won't be able to change this table in customizing in the predefined path in SPRO/OLML, but will need o do it in SM30.

Luckily both of the options should work fine if done correctly, I have used both of these, and both have up and down sides... But I would go with standard SAP if it doesn't complicate your life too much because of several more STs. If it does, go with ABAP.

[Former Member · Accepted solution]

I will try both ways and will see if that works. Maybe too much storage types would be confusing for everyone to manage,but it may be better because we dont have abap consultant. I will try on dev-qas the first option and see if it is manageable.

[Former Member · Accepted solution]

I chose first solution,no ABAP,works ok,maybe will be confusing in start but people will get used to this.
Thank you.