cancel
Showing results for 
Search instead for 
Did you mean: 

Completion of Shipment Delivery not Updated

Former Member
0 Kudos

Dear all,

I am facing a strange problem, and I hope you could help me sort it out.

Basically, when a shipment of material is delivered, it is stored in the LIPS table, as well as in MSEG as the logistics document. Also, the history of material delivery is saved in the VBFA, and the status of deliver - whether it is complete or not in case of delivery via multiple shipments - is placed in the VBUP.

Now, in our case, we receive materials of a Purchase Order (PO) in several delivery rounds (shipments). The quantity of delivered materials is saved in LIPS correctly. Also, in MSEG we can see that the logistics document for each shipment is generated correctly.

However, sometimes when the shipment of a PO, which is usually delivered in several shipments, is complete, the completion status is not updated in VBUP, and therefore, the system still accepts more material for the purchase order. Consequently, this leads to delivery of excessive material to the PO.

As I said, it does not happen all the time. We suspect this to happen when the load of the Prod. server goes dramatically high.

Does anyone have any idea why this happens, and how to prevent this?

Thank you,

Arman

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi all,

Maybe I can formulate the problem statement in a more expressive format.

Usually, we receive materials (Inbound Delivery) through BORGR_B. Accourdingly, a logistics document is created in MSEG table.

The problem is that, sometimes, when an inbound deliveries is complete, its status is not set in VBUK table as 'C'. Consequently, in VBFA table, the relation between material document and inbound delivery is not specified.

Therefore, the inbound delivery will be still available in BORGR_B and we can still post material to it, which leads to duplicate receiving of materials. This rises the quantity of posted material higher that the allowed quantity of inbound delivery, which is obviously an error.

Now, is there any solutions to this?

If the problem statement is still complex, please let me know so that I can provide an example.

Best regards,

Arman

JL23
Active Contributor
0 Kudos

You actually just added a transaction which did not make the scenario much clearer (contrary I do not even know the BORGR transaction as it is specific to an industry solution).

Anyhow, my main point is, if I order 100 and get 100 then this order is completed for my vendor and for me. An incorrect status in VBUP is probably a bug in SAP or wrong process understanding for the person at the keyboard. see OSS note 1050944 - GR for inbound delivery using inventory mgmt as of ECC 6.00


But even in case this status is not completed, it can only be a human error with a wrong entered number to receive more quantity to this delivery.  Your description actually sounds like you will always get more quantity if this status is not correct updated. From my point of view it can only be a rare exception, a user fault. Based on what info does the user do a receipt? Does he not have paperwork with the number?

Former Member
0 Kudos

Un-till and Unless you assign new delivery number in shipment document you cannot receive more as already delivered by your supplier in actual shipment what PO is needed.

JL23
Active Contributor
0 Kudos

I guess you are talking about inbound deliveries, right?

When you are saying shipment, do you mean the transaction VT01N ?

How is the receipt posted? Via VL32N or MIGO, you see this in the header of the material document.

I can't really believe that it consequently comes to delivery of excessive material to the PO.

How can your vendor know that you have a problem with the status update? Why should he then deliver more than ordered?

If the physical movements match what you ordered then it will not come to any overdelivery, further has the PO fields for over- and underdelivery tolerances that actually control if you can receive more than ordered.

Former Member
0 Kudos

Hi Jurgen,

Thank you for your answer. Bellow, I reformulated the problem. I hope it could make the scenario more clear for you 🙂

Thanks!

Arman