on 06-22-2015 4:39 AM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
94 | |
11 | |
10 | |
6 | |
5 | |
5 | |
4 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.