INVENTORY CLOSING CANCELLATION

Hi

Getting this infolog on cancellation of inventory closing.

" Error Infolog for Job Cancelation - Initialize (5637147581)\Infolog for Task Processing item ITM-002345 (5637204746)\Item ITM-002345 Cannot edit a record in Inventory transactions (InventTrans).

The record has never been selected. "

What could be the reason and solution? Secondly, how can we trace on which particular transaction of inventtrans is this error generating?

Rgds

Akusman

I would start by getting a developer to de-bug and tell me exactly what is wrong.

We had run inventory closing with Weighted Average as inventory model group. Then as required by the user we changed that to Weighted Average Date. After changing that we were cancelling all previous closings for few months cancellation went fine then this error occurred on cancelling closing for one of the month.

Why did you not cancel all previous closings THEN change to weighted average? Your approach would only cause issues. I assume this is in a copy of live and not live?

Yes, its a copy of live. Adam we have ran complete inventory closing with new inventory model group and now cancelling them to run closing again with increase throughputs for accurate costing. so I don’t think that changing inventory model group before cancellation would have effected it. Sorry, forgot this point in my post.

I would suggest it has, but you need a developer to debug it and tell you exactly what is triggering the cause so you can try to understand it further.

After going through code that was throwing error it say that their are some Settlements that have no ref in InventTrans. Just deleted those settlement through SQL and it worked.

rgds

Akusman

Hi Akusman,

your Settlements you mentioned has been posted or not? And have you did it on your live system. Do you face with any issue relevant?

Anh Mai,

As written before that we had deleted those Inventory Settlements whose record does not exist in InventTrans. We had this issue on our test server.

You need to track the source of the rogue transactions to prevent it happening again. You have not solved the actual problem here.