Hi hansacha 

I think we have various experiences in this forum on how to face this requirement.

I understand the reluctance of your consultant: changing DES data  type will impact 375 differents tables and even more screens!!

The size of the field has a direct impact on the display and you might need to adapt many screens. So technically, this change is simple but the impacts are so massive that you need days of testings and troubleshooting for a 2 min change. Second major impact is about the cristal reports, almost all standard reports would need to be modified to accomodate the extra space needed.

So another approach can be to create a new data type, which will be 60 characters long and only apply it to ITMDES1 so at least the impact would be lower.  => Beware to have a proper translation you need as well to adapt the AX3 data type linked to DES1AXX. Still you need to cope with the impacts on screen / reports using ITMDES1 and plan for some tests, it still a budget to sell to the customer. To reduce the budget, you can see if the customer agree that the classic screen only displays 30 characters so at least you can benefit from the full text upon object selection (and the grid I think). Regarding, the report quite often the customers are tailoring them so it would be an additional task on their side, else you need to identifiy the report to modify in order to have a correct estimated budget to sell. On the top, because now you modified so many standard screen (with an activity code), the cost for the maintenance of the solution would increase. You can find a feedback on this approach in the following thread: communityhub.sage.com/.../326810

Another approach that would allow to better control the impact and reduce the maintenance is to create a new custom field based on 60 Characters. You can check this thread that deep dive in this alternate approach:  RE: How To increase the number of Character in the product Description field. 

Thanks Julien for the detailed answer.

Maybe the new data type can be a solution... I read since I wrote this message that a problem would rise from hard coded processes taking only 30 characters. This seems an odd approach to coding in my opinion, but maybe it is 'legacy' coding. I do not know which version the post I read was relative to... We have a 23 version here, so I was hoping these processes were rewritten using the data type size...

The post refers to the generation of a PO from a Purchase request, which is on our workflow. (My needs are for the tasks, articles, purchase requests, PO and SO lines, Invoicing... etc that all hold a similar info during a project lifetime in our context.)

Does anyone have precise info on this 'hard coding' issue ? This is my main issue. Presentation issues on screen or crystal are easily managed in house (I am client side).

TIA !

hansacha said:

I read since I wrote this message that a problem would rise from hard coded processes taking only 30 characters.

I have seen this post. It was from U9 (8 years ago), a global variable (WITMDES1 in the process TRTACHPOH1) wasn't based on the data type. If the issue was reported to Sage support, I expect it to be fixed. Anyway, keep in mind when defining the budget that extending number of digits needs to be tested and some fixes will probably be needed.

>>My consultant is reluctant to do it and I do not get why...

Probably because it effect a lot of fields in a lot of places.   

We created a new data type and field.  Never cchange a data type.  

The field is 90 characters.   When a person types a description in the long description field it breaks it using proper word breaks accross the three thirty characters existing fields.   This leaves most of the functionality intact in the system and lets us choose where to change it.   We have changed it on all used sales orders, invoice and Purchase orders screens and probably some others I can't remember.   We have added another 90 character field for customer description and vendor description so that these can be the same lenght so if they are edited on an SO or PO they are correct.    We have modified the forms in crystal to use and wrap the fields.

Meanwhile, everything remains intact that uses the 30 character fields.

We also added a multi word search function to the screens so you can search on this field on multiple words. 

On this screen they can see what they have that fits the description and if another location has it.   So if you don't have the first one you can suggest the other or even see if another location has it.  

It does pick up words in words (textuRED) but that can be good too.  

Happy to "share" the code but probably need involvement.  I have given it to one other consultant and they didn't really understand it and they hosed the implementation.  Their search does one word like contains does.

Use new data types. Also if you are planning to go to 60 you might as well go to 80 as it is no more extra work. 90 characters is not good an X3 does not like it.

The data between Requests and Orders, in purchasing, has not been fixed to my knowledge and there may be other foibles like that.

We have successfully done this update for a few clients, on different versions, but it is never as simple as you believe it will be.

>>90 characters is not good an X3 does not like it.

What is the issue with 90 Characters?   When does X3 not like it?

We are using 90 because it's the length of the description fields put together (3 X 30).   We are not having any issues that i know of and it's been in production for several years.   So if there is an issue i am of course concerned. 

HI Stephen, cannot remember off the top of my head but I do know that we found 80 characters to work across the system without too many problems.

If I can find my notes I will let you know