TO creation from TR from OBD transfer receipt

[neil_peltier]

I have a material in main plant that is to be sent to another processing plant. Process is create UB PO for item, then create OBD from this PO. Pick SU(s) to OBD and then PGI OBD. Process in receiving plant is to receive via MIGO the OBD. Flows to INB Inbound and then to FRZ Freezer where it should get SU number. The GR document shows Immed TO but looking into the TR it is not processed. Going to LT04 to process TR in foreground all appears normal FRZ Freezer shows storage unit. When trying to confirm from this screen sap errors "Storage unit xxxxx is not consistent with other transfer order data" message L3208. Viewing the SU number in LS33 shows the SU is from the original sending plant with that plants warehouse, storage type, and storage bin so cannot be completed. Has anyone seen this or have suggestions? Thank you for the help.

[neil_peltier]

Does anyone have any suggestions on how to remove the destination SU number that is being populated from the sending plant? Should generate its own new SU number.

[JL23]

usually the storage unit is lost when you move the material from your bins to storage type 916 for goods issue. This can be seen in many discussions where people are actually astonished that the number is lost  and it can also be read in Stock Removal With Storage Unit Management - Warehouse Management System (WMS) - SAP Library

So I think this is either caused by an own opportunistic programming that moved this SU number over, or by a SAP bug.  Probably no way around debugging, especially if you can replicate this case.

[neil_peltier]

Correct, when the SU is transferred to the 916 in the sending plant it is gone which is all fine and good, but upon the GR in receiving plant during the TR processing it fails to create the TO because the destination SU comes from sending plant. So you suggest contacting SAP then since this is happening every time?

[JL23]

I would check if there is not any modification or exit that causes this behavior before  contacting SAP.

Maybe any copy routine in case you create inbound delivery from outbound delivery.

[neil_peltier]

The only thing that is very curious is that it is just this single plant that behaves this way. Sending back to the original plant or to/from other plants works as expected which is strange. They are all using the same OBD information. You have any suggestions on where to start looking?

[JL23]

you could probably start at a different point as you know your environment better than I do.

But with this limited information, I can just ask further questions which can be taken into consideration for an analysis.

e.g. is this a new plant? is it the first business case in a new process? Could you do stock transfers for this plant in the past without problem or had it never worked?

When did it start to behave differently?

I would check customizing transports. I would look for modifications and exits, e.g. with the program SNIF. I would probably send an email to all my consultants and developers supporting this system. I would debug. Investigate functional specs, technical blueprints and change requests.

[neil_peltier]

It is not a new plant and it has been behaving this way for some months now according to the users, I believe around the time we upgraded. This process had worked in the past.

[JL23]

I wouldn't think that the upgrade could cause such issue.

If there were a change in SAP's program logic, then it should affect all your plants.

SAP cannot know your plant setup, hence a change could not be plant specific.

Plant specific means that there must be some customizing that could cause this. I am not aware of such, especially as the behavior does not match with the documentation.

Is this eventually a special process compared to other plants. e.g. that those 2 plants share the same warehouse and you actually do posting changes  instead of goods issue and goods receipt.

Or...because of the same warehouse a logic was implemented to keep the same SU number to avoid relabeling.

[neil_peltier]

I would not think an upgrade would affect a single plant as well. All 3 plants have different warehouses and they all follow the same process with PO, OBD creation and picking as well as receiving the OBD. It could be something to do with a logic to keep the same SU number, where would I review that? I have looked under WM SU setup for all 3 plants and they are the same with assignment type 2 (internal number assignment and use of prev numbers).

[JL23]

To my knowledge there is nothing in SAP to keep an SU number when moving to another plant. Hence I would search for programming e.g. via debugging or by executing SE38 with report SNIF