Intrigued to know how you did that as Key change is not normally an option for master data such as products, BPs sites etc.

I used key change setup to create a change on the ITM object from old SKU to new SKU and executed it.

Hi, 

I had the same issue recently, but i just look into the atabzon for the tables who have a field with the ITM/ITS/ITP datatype and checked if the values in that tables were fine. 

I think just the stojouval table was not ok.

I want to believe this function works because  i have used it to change item number and have not had an issue as far as I KNOW.  

My questions center on whether what you found is an error or the correct behavior.   I would expect that it would replace the keyfield where the object ITM was referenced but it seems like that would not yield the results you found.  

>>in SQL and still see the old item code in STOCK

What is the status of that old record and does the new record exist?   Can you still bring either record in the user interface? 

>>Neither code in ITMCOST

So it didn't exist before and doesn't exist after, so that's okay?

>>both codes in ITMMVT

That one puzzled me most.  Are the old movement records somehow inactive? 

>>and the new code in STOJOU.

This is the behavior I would expect. 

The function seem to use the object ITM as it's reference point in making changes. I think that may be an incorrect interpretation on my part and it should or does use the data type ITM to locate and make changes but i am guessing.

I'd like to understand this. .  

Thank you.

Fortunately, we had migrated a new test environement moments for performaing the key change. So I was able to use that today and dig a little deeper. I exported all the IT, ST, SO and SI tables that had the item in them. Ran the key change in the test environment, and found the old code in ITMMVT, STOCK, and STOJOUVAL. Everthing else was changed to the new code. What did you end up doing to correct the STOJOUVAL table?

Fortunately, we had migrated a new test environement moments before performing the key change. So I was able to use that today and dig a little deeper. I exported all the IT, ST, SO and SI tables that had the item in them. Ran the key change in the test environment, and found the old code in ITMMVT, STOCK, and STOJOUVAL. Everthing else was changed to the new code. 

>>in SQL and still see the old item code in STOCK
What is the status of that old record and does the new record exist?   Can you still bring either record in the user interface? 
>>The old record still shows in STOCK with the qtys that were there before the keychange. The new record does not show in STOCK at all. I cannot bring the old record into the user interface. X3 acts as though it does not exist. I can bring the new record, it shows no stock, but otherwise works as expected. 

>>Neither code in ITMCOST
So it didn't exist before and doesn't exist after, so that's okay?
>>Correct, it did not exist before. I wasn't sure until I ran it again today in the test server. I believe that table is fine. 

>>both codes in ITMMVT
That one puzzled me most.  Are the old movement records somehow inactive? 
>>In the controlled test, only the old code is still in the ITMMVT table. In the live system, I suspect it showed both from the before and after the key change.

So it seems to work for everything except stock. If there is no stock in the item changing codes, then probably nothing to worry about. The question now is how do I get around it. I have two ideas, neither I am thrilled about, I'd rather there was something native. I'm certainly open to other ideas as well.

1) Do a micellanious receipt to remove all the inventory in the old code, run the key change and then do a miscellaneous receipt to put the inventory into the new code or
2) Use in lines to copy all the old code records into the new code and then delete the old code records. (I like this idea better, but it's probably riskier)

The key change option is not available from the Product record directly because it affects so many tables. That should give you a clue as to why it is such hard work.

Just be aware that any data amended in this way, against the accepted key change functions set by Sage may allow Sage to deny you support if you blow anything up.

Thank you very much for the detailed response.  This is not what i was expecting.    I'm sure this will come up again and i will rerun the test before i try it live and document it.