One of putaway strategies in standard EWM is called “Storage Behavior: Flexible bins”. The documentation for this feature describes the customizing steps nicely. What is not described there, is the main idea, the concept of this feature. This is, what I try to formulate bellow.
Flexible Bin Concept
The standard concept is working with a network of cells of same size (x & y dimension). This network can be used to create new flexible bins of different sizes, consisting from 1-n adjacent cells. It is obvious, such bins are more likely directly on the floor, in a warehouse area without any fixed racking structures.
A bin can for example be named as combination of
- prefix (area)
- XY coordinates of lower left end cell of the bin
- XY coordinates of upper right end cell of the bin
“A1-0302-0303” reaches from cell (X = 03, Y = 02) to cell (X = 03, Y = 03) in the area A1
You define the pattern for these bins in transaction /SCWM/FLEXBINAREA:
These bins are created either:
1. during confirmation of a WT (bin in a specific format is entered in NLPLA)
2. by a Badi during creation of a WT
Option 1 needs to create primarily a putaway WT without specific NLPLA bin (see “WT Generic” in customizing of Storage type).
However, it is hardly possible the user could correctly specify the name of the newly created bin using above described logic (specifying lower left and upper right cell of the bin he’s just used for putaway…)
Option 2 is more likely to be used. The logic in the example code for Badi /SCWM/EX_CORE_DYNBIN_DESTBIN tries to determine the next available cell in the network, and to find how many adjacent cells are needed for putaway of the certain WT item.
It is only pity the number of cells is determined on hand of length and width of the basic UoM of the product being putaway(…), instead of using of measurments of the HU for example. But, it is only an example code, of course. You are free to engage with your own logic.
Finally, Badi composes the name of newly assigned bin (e.g. “A1-0302-0303”) and WT is created with this target bin already.
It is, again, a bit tricky to imagine, how this new bin code will be confirmed on RF… There will be probably no bin label to be scanned in this case. More likely in this case the destination bin will not be required in RF (by customizing of confirmation control).
Flexible bins are automatically deleted
when being emptied, at least in standard. Freed cells are available for composition of new bins again.
There is a bit mismatch in terminology around this topic. Although “Flexible bins” is used in the end-user interface, the main class is /SCWM/CL_DYNBIN and also in the code is mostly referred as “Dynamic bins”.
This can lead to mistakes, as the term “Dynamic bins” was rather used in WM, in case of bins in interim storage types 9xx, which vere automatically created and deleted by system. These bins, however, were used only technically to distinguish for example original Purchase order number, but did not represent a physical area in the warehouse.
Main concept of “Storage behavior: Flexible bin” is clarified and possible use-cases are presented.