In the child folder, go to Setup > General parameters > Parameter values:  in the left list open the "ADX Adonix" chapter.  Open the FMT Formats Group, select "Detail".  In the TUL01 parameter value, the standard setting is cA#:-/_   Add the period after the underscore.  Select <OK> then Save.  Log out of X3 then re-login for it to take effect.  This will allow the period character in product codes, customers, etc.  Must be done in all child folders the period is to be allowed in key fields.

This should be considered as a customization so that change can be done in the early period of an implementation without having a large impact on the cost (because most of the testing is still ahead of you).
BUT if anyone else is using this discussion for a different context, please beware this should not be done without proper testing.

Julien, thanks for the cautions.  I was only responding to the question about allowing the period character.  Though some special characters like a period are likely compatible, many other special characters may cause unpredictable results or at worst corruptions within the database. Thorough testing is certainly required. 

One more follow-up to this topic, is there a way to increase the item number field from 20 to 30 characters?  Below is an example of an item that is 24 characters long.  

HDAMTLN450-3545-180TJ-25 

HD =      heavy duty version

AMT =    a particular style of #######, with a 185 front housing and standard rear housing

LN =       fits a ##### #### with the old-style ######### ### bushing

450 =     450 ###

3545 =   for .035 to .045 #######

180TJ = has a ###### installed, instead of the standard AMT ####### front end fitting

25 =        25' long ########

This part number gives our assembly department all the information they need.

Hi Britt Madden 

I have always considered this change being too impacting because this change the size of the ITMREF field in so many screens and reports that the cost will be very large (especially the testing). In addition, you are not sure that some processes will not failed due to this change, so again a massive effort in testing (up to 3rd party integration).

I would recommend you to change the product codification rules to stick under 20 digits. This still offer over billions of combinations.

Is there anyone in this forum with experience on doing this kind of change?

To soften the impact of a prodcut code, you can offer to store this old value in the ITMDES3 field and make available upon product selection or try to enlarge the UPC code (less impacting) to store this value. But from experience, if you decide to change the product code, it is better to avoid letting the end-users using both the old or the new code. Else, the transition will never be complete.

Thank you !  I appreciate your help and guidance.