In theory, you should be able change the length on the ITM datatype setup, and do a dictionary validation for everything filtered by ITM datatype. What this will do is it will increase the length for all ITM data type fields on all screens and all tables. 

The thing is, it's under the assumption that all product fields are tagged with ITM datatype. While that may hold true 99% of the time, there could be that 1% out there that are not tagged as ITM due to either oversight or program limitation. 

One example would be price list. Since you can use any field as pricing criteria, it can not be hardcoded as ITM datatype, instead, it's a generic field that allows 40 character. While this will not cause the problem when you increase to 30 characters, but for those who want to increase beyond 40, this will become an issue.

I personally believe that the only solution is to make this change in a Dev environment first and test. 9 out 10 you will probably be fine, or the 1% occurs on functions you are not using.  But the key is to do a thorough testing on all processes to make sure nothing breaks on the functions you do use. If you see any error, report it your partner and it's likely a easy fix. 

In theory, you should be able change the length on the ITM datatype setup, and do a dictionary validation for everything filtered by ITM datatype. What this will do is it will increase the length for all ITM data type fields on all screens and all tables. 

The thing is, it's under the assumption that all product fields are tagged with ITM datatype. While that may hold true 99% of the time, there could be that 1% out there that are not tagged as ITM due to either oversight or program limitation. 

One example would be price list. Since you can use any field as pricing criteria, it can not be hardcoded as ITM datatype, instead, it's a generic field that allows 40 character. While this will not cause the problem when you increase to 30 characters, but for those who want to increase beyond 40, this will become an issue.

I personally believe that the only solution is to make this change in a Dev environment first and test. 9 out 10 you will probably be fine, or the 1% occurs on functions you are not using.  But the key is to do a thorough testing on all processes to make sure nothing breaks on the functions you do use. If you see any error, report it your partner and it's likely a easy fix. 

Technical notice:

Ensure the standard data type you are customizing have a custom Activity Code.

Truncation is guaranteed without preemptive notice in the future if you did not have a custom Activity Code and Sage X3 decided to revert back to Sage X3 standard as part of X3's Folder Validation.

You can observe my suffering here but for AX3 and when there's a migration work / update or upgrade work / Sage X3 license changed:  Data type: AX3. How to extend characters?