cancel
Showing results for 
Search instead for 
Did you mean: 

Not able to cancell picking for delivery using trx. LT0G

Former Member
0 Kudos

Hello,

For an outbound delivery, the user had done the picking a long time ago and the stock were there in 916 storage type and the dynamic bin, but the goods issue was not done.

But some how the stocks got consumed from 916 storage type.

Now the user wants to reverse the Picking using trx. LT0G. Hence he had built up the required stocks in 916 storage type and the dynamic bin, to reverse the picking. But when he executed trx. LT0G, all the lines are appearing locked and no stocks & material is appearing. Hence not possible to do reverse the picking.

Please let me know what may be the problem.

Thanks & Regards,

Sumanta

Accepted Solutions (1)

Accepted Solutions (1)

Former Member

Hi Csaba,

Thanks for your reply.

As I had said, the user had manually adjusted the stock from 916 and hence no stock existed in 916. And Goods Issue is still open.

Now he has build up the stock in 916, so that he can cancell the picking using trx. LT0G. But all items are appearing locked.

I saw that using trx. LT10, the items are not locked . It is possible to move the material stock using trx LT10.

But if LT10 is used , can the user again do the picking for this delivery using trx. LT03?

Please let me know.

Thanks & Regards,

Sumanta Deb

Former Member
0 Kudos

> Now he has build up the stock in 916, so that he can cancell the picking using trx. LT0G. But all items are appearing locked.

> I saw that using trx. LT10, the items are not locked .

Has the TO for building up the stock been confirmed?

If not, the stock must be in state "receiving". It's locked for futher moving, but may not be marked as locked in LT10. Check open TO's via LT23.

But if LT10 is used , can the user again do the picking for this delivery using trx. LT03?

Please let me know.

Since the OBD has status "picked" user can not do the picking for this delivery again, until LT0G is performed.

IMHO to solve your problem, you should form the stock in 916 with LT01 (LT10) taking batch into account, and then perform LT0G.

If it doesn't help, try to enable negative stock indicator for 916. Run LT0G. Then line up the negative quantities generated in 916 with corresponding stock from the other storage types,

Hope it helps.

csaba_szommer
Active Contributor
0 Kudos

Hi Sumanta,

I've checked the same in the system I work with and my experience is the same.

I don't know how to solve this, since the problem seems to exist in the system itself. I think you should follow what OSS note 535803 says and delete the delivery and ceate it again.

You can also contact SAP and inform them about this deficiency of their software.

BR

Csaba

Former Member
0 Kudos

Hi Csaba,

Thanks for your reply. As you know the user has already buit up the stocks in 916 storage type. And there are also no open TOs. But while doing LT0G, still the items are locked.

Actually the main problem was user was not able to do the Goods Issue because picking happened without the batch. Hence it was not allowing to do the Goods Issue without the batch.

To solve this problem, I think I should enter the batch using direct table update in table LIPS and then using direct table update I should make the WM & picking status to C in VBUP & VBUK table.

Then ask the user to do Goods Issue.

I hope this should work.

Thanks & Regards,

Sumanta Deb

csaba_szommer
Active Contributor
0 Kudos

Hi,

In my system I did:

1. picking

2. removed the quant from 916+dynamic bin by LT10

3. restored the stock by moving the same quant to 916+dynamic bin

WM status remained the same, same quant is in 916+dynamic bin still I cannot perform LT0G - the item is locked.

PGI is possible, there's no problem with it.

You may be right, if you change the fields in the tables manually, it can solve your problem but it is not standard process:)

BR

Csaba

Former Member
0 Kudos

Hi Csaba,

Thanks for your reply.

In your case the PGI is possible because you have the batches and also the WM status in your case is C.

But in my case since there are no batches and also the WM status is B, hence it is not allowing to do the Goods Issue.

But you are correct that after removing the stock from 916 & again putting it back to 916, system does not allow to do LT0G as it shows all items as locked.

What do you say should I raise a OSS message to SAP OR should I solve this problem using my method by entering batch & change WM status using direct table update.

Thanks & Regards,

Sumanta Deb

csaba_szommer
Active Contributor
0 Kudos

Hi,

Even if I do picking, batch no. doesn't appear in VL02N for the item, so I'm not sure this is necessary.

What I do not understand why your picking status is 'B'. If I remove the stock manaully (LT10) from dynamic bin, the picking status doesn' change.

If someone removes the stock manually from dynamic bin it is not the standard process. I think it violates the document flow and it won't update the status on delivery document.

However I cannot see why cancellation via LT0G should be locked, why it should cause incosistency.

I think you can ask SAP AG what their opinion is about the solution but I guess, generally, you have the two options we were speaking about:

- delete the delivery document and create it again (even you can create it with the same no.)

- your solution that is manually modify the data tables

In normal case I think option one should work, since users have no understanding of data-table modifications.

I do not know whether it costs money to raise such issue at SAP, but if it is free I would ask them how this should work.

BR

Csaba

Answers (1)

Answers (1)

csaba_szommer
Active Contributor
0 Kudos

Hi,

1. Generally, do you have this problem?

2. You said GI was not done. What is the status of your delivery (all status fields, especially WM)?

3. How was the stock 'consumed' from 916+dynamic bin?

4. Could you move the goods via LT10? I mean can you see the items as locked in LT10?

If the answer for question 4 is 'yes' you could check OSS note 535803.

BR

Csaba