TR/TO/Quant number range reset Issue

[Former Member]

Hi,

We are having problems with number range getting reset automatically when we execute the WM transactions and wanted to know solution if anybody faced similar issues.

Scenario:

The warehouse has been setup with only one storage type which has open storage putaway 'C' and removal strategy 'H'.

The stock is received into the warehouse via 301 plant to plant stock transfer wherein TR & TO is created to putaway stock into open storage. the only other scenario in this warehouse is standard picking that happens via LT03 based on SLED.

Problem:

I have observed that the system has reset the number ranges for TR/TO/Quant durimg standard transaction execution like MIGO, LT03 and then we get express document notifying the number range already exists in the system. This is because the system on subsequent execution is trying to assign number range that already exist in the system.

I have checked the change log for number ranges and there is no recent change log that has caused the reset. I have also changed the number range manually to current number and still found that after some executions the system has auto reset number range to initial.

It is strange that we are only executing standard transactions and no custom developments involved.

If anyone has faced this kind of issues or any hints on the fix, Please let us know.

[JL23 · Accepted solution]

I have not yet seen ABAP coding that does something without having been called interactive by a user or had at least been scheduled by a user.

The number ranges work with buffered numbers, usually 10 numbers are in a buffer.

so even you have manually changed the current number the buffers still have numbers from the old number range. so in worst case you would get 9 more dumps until SAP read the next 10 numbers from the range.

Check the transportation logs in STMS to know if someone transported the number range from Development system to your production system. As you usually have less number taken in a development system  a transport will certainly add a number as current which is already taken in production.

you can directly check the number range in DEV if the current number there is close to the number that you found in your production system as you got the express documents. Then you can be 99%  sure that someone has transported this number range.

[Former Member · Accepted solution]

Hi Juergen,

Thanks for your reply. This is the development system(testing client) where i am facing the issue. The number range has not been transported from config client to testing client I have checked the logs. Also as i mentioned i have changed the current number manually three times and yet it is resetting after few transactions.

Please let me know if there could be other possible resolutions.

Best Regards,

Harish

[JL23 · Accepted solution]

Unfortunately there is no change log for changes of current number. 

The only chance I see is to revoke authorization for number range maintenance from anybody else than you and then check if this problem occurs again.

[Former Member]

This was due to number range import problem that got resolved now.

[Former Member]

This message was moderated.