Need Ideas For Storage Units Data Storage Capabilities - Special Attributes? History? 2 Ind-UMs

[Former Member]

Hello experts,

The company I'm working for is looking into permanently-storing pallet level information (keep a history of the pallet movements) and use RF-scanners to move product in the warehouse. They have made a decision to implement Warehouse Management's Storage Unit Management functionality. They looked into Handling Units as well, but they don't want to use HUs for many reasons.

They would also like to store 2 units of measure at the Storage Unit level without activating "Catch Weight Management" because that would require them to run parallel systems for a while and also deal with CWM functionality restrictions. Keep in mind that most of the products they handle are catch-weight products, so UM conversions don't work for them.

Solutions I have in mind:

For storing 2 independent UMs: Store the quantity of the 2nd unit of measure in a custom table at the Storage Unit level and use custom RF-scanner programs to "receive, issue, scrap, and move" goods in the warehouse. These custom RF-scanner programs would update SAP standard table with 1st (base) UM and also custom table with 2nd UM.

For permanenlty-storing SU history: Use custom table to to store Storage Unit History. The custom programs created to handle the SUs would update this custom table.

Last time I checked, the history of a Storage Unit is not recorded in SAP, correct? ONLY in Handling Units, correct?

OR are there any documents/tables that permanently store the Storage Unit number so they can be queried after the Storage Unit is consumed/issued?

I know SAP keeps improving its applications with every release, so I'm just looking at my options here.

Does anyone else have any other ideas on how to approach this other than Using Handling Units & Catch Weight Management?

Thanks in advance!

-Mr. Bello

Message was edited by: Jürgen L

[MANIS · Accepted solution]

For storing 2 independent UMs

Can you please explore the LS26 option there also system is allowing you to change the parameter"Unit of measure" and displays the stock on different UoM, hopefully this will solve your problem and you need not design a custom table to store the value at different UoM level

For permanenlty-storing SU history:

System store the storage unit related value in table : LEIN however the moment you do any consumption or movement to non SU the entries goes off from this table hence i think the approach taken by you seems the only one approach  to store the historical data. (Make sure you are taking into consideration of the archiving activity as you proceed further the size of database will get bigger and time to generate any report will take longer then expected

[Former Member · Accepted solution]

Hello Manish Kumar,

1. About the 2 independent units of measure: I understand that LS26 uses a conversion factor. As I stated previously "Keep in mind that most of the products they handle are catch-weight products, so UM conversions don't work for them." In this meat processing plant, every case of the same material has or can have different weights, so I'm just wondering if there is an alternative to using SAP's Catch-Weight Management (CWM).
2. Your information about permanently-storing SU history was very helpful and appreciated. Thanks!

Mr. Bello

[MANIS · Accepted solution]

Hi

I don't see any other option other then storing the value in the custom table as you mentioned earlier hence in my view also if you want to avoid the HUM and Catch weigh management module then the approach / solution mentioned by you is the only solution which can help you to achieve the desired report.

Since you are trying to avoid CWM module. In my opinion there are few more point which needs to be taken care,By using the above method you can record the transactional data however during dispatch you need to pass the catch weight detail on the shipping document which leads to another development. If the shipment got return by the customer then you need to write the logic differently to store the detail in temp table for identification and reporting. Any internal WM activity where Catch weight managed information are required that need to be considered thoroughly

[Former Member · Accepted solution]

That's exactly what I needed to hear. I will mark this as the right answer. Thanks for all your help Manish Kumar, you are always a great source of help.