Inventory Description 2 problem

Dear all gurus,

Our system has set the item description 2 to 50txt space.

But 50 is just not enough and we wish to increase to 100 if possible.
Our MIS ppl has extended the txt limit to 100txt in “item” table which allow us to key in
up to 100txt.
but when we are issueing Sales Order, the error comes up

“Overflow under type conversion of text to text”
Value: xxxxxxx xxxxx xxxxxxxxxxx (description 2’s wording)

I think the MIS ppl has done the wrong way. Can you guy help me pls.

TQ

seyhock

In general it is not a good idea to increase the size of the item-description field (or other description fields) [and even less code-fields].
It is better to create a new field with the full description, and transfer it from table to table and use it in objects where you need it.

I have three opinions on this;

1/ Don’t ever do this.
2/ Don’t ever do this unless someone is pointing a gun at your head,
3/ Don’t ever do this unless someone is pointing a gun at your head, and you are 100% certain that the gun is loaded and the person really will pull the trigger.

[;)]

Even with the third option, I would still have doubts to do it or not. [:D]

[:)] LOL, did you get fed of explaining the In’s and Out’s of this, so just found a simple generic answer?

/TH

David you really should stop sitting on the fence, and beating around the bush, do you think they should do this or not? Just state a forthright opinion please [:D]

Is the person in point 3 the same person holding the trigger and having the gun pointing at them?

Come on guys, this is the description 2 field, it is not a primary key, it is nothing special, just give him the solution. As an end user I can’t believe this is that big of a problem.

But as an end user I can suggest a solution without coding that may work

use extended text instead, that involves no coding, and will allow you basically an unlimited amount of space to put in a description.

But really, this is not a major field, there isn’t even a key involved, the code has to be as simple as changing the variable lenght in the sales order, and probably purchase order it is just a small amount of code in the sales order that combines desciption 1 with description 2 to create the description inserted in the sale order.

Sound like the problem can be solve.
Just ask the programmers to change the repsectively affected areas.

Btw, the provider suggest another solution, they are proposing to add Description 3 as another column.
Which I think it is also acceptable.

TQ

I understand that at first glance it really does look this simple, and its why people do it. The problem is that the description fields are used in more places than you could imagine. Many are places you don’t even discover for months after the field length has been increased. There are just so many places that the field is used. I have seen this modification made so many times, and have heard so many panic calls such as “we are trying to create a credit memo from an invoice and we are getting an error”, being a common one.

Of course I do think that Navision should make this change globally and extend description fields to 80 characters, and Address fields to 50, but as we heard at convergence, this is not likely to ever happen.

Yes this is a very good solution to the issue. It just needs the user to look closely at their business processes and see how to integrate them with Navision.

Generally I go with a solution of adding a new field “Extended Description”.

Oh and another problem, is that although the code is quite simple, it is just in so many places, that one will be missed. but more importantly the killer is that once the NSC changes the Item Description, the customer then says, hmm that was easy, lets now change the Customer names and addresses, these are used in the address formatting code unit, and they may not bother with areas they don’t use like contact manager, and these things all bite you later.

Of course once that is all resolved, the client then starts looking at changing the Item No. field.

Basically changing the length of the Item description is always just the first step in a long path to disaster.

True, I learned that years ago from another collegue (lucky me [A]) who did it, not knowing what was waiting for him.

Hi, seyhock! Read carefully what David wrote.

And there is another issue: If the customer has to upgrade to a newer version, it will be more expencive to the customer as several of your modifications probably have to be done all over again. Ok - if the customer have to pay - alternative: you pay.

NAV 4.0 SP3 had changes in some 300 objects in relation to SP2. Do not know the number of changed objects in NAV 5…

Btw - MS should consider implement “Extend Data Type” in NAV. MS Dynamics AX has this feature - great!

EDT is kind of a global, userdefined variable used as a parent.

E.g. ItemDescription is defined as an EDT, Text(30); tablefield Item.Description is defined a Text “connected” to the EDT - and is thereby a Text(30) as well. Everywhere in the system when relating to Item.Description via variables, the variables should be connected to the EDT.

Now - if you change the max-length of the EDT, all “connections” changes - and that is all you have to do…

I had went thru all the reply and decided to change back to 50 char for descp2 and add a new descp3.

We wish to do it ourself to split the description to descp2 & 3 instead of asking the system provider to do the changes.

It is kind of frustrative if trouble the system provider to do this is a major issue for them when you are the one who pay them the money.

“Our MIS ppl has extended the txt limit to 100txt in “item” table which allow us to key in
up to 100txt.”

If they are willing to do this without thinking about the ramifications that this will cause - I would be very nervous about any changes they make.

Time for new MIS ppl - LOL!

In conclusion, it is a very complicated and uncertain if we wish to change the standard character space.

Why not Navision just dont allow to change the character space or

if it is allow to change, then changes shall make globally so that all effected area will update automatically.

Anyway, we got the solution that if system is not unable to suit our requirement, then we have to change ourself to suit the system.

Thank you all!!

Just a quick thank you to all who have posted in this thread, it has helped me very much [:D]

When I get end users looking for bigger Fields Like Item Description or Customer Name etc. I will create a new field from them and make changes to those reports which requires the information to be viewed or accessed. Change the sizes of the default fields is a BIG RISK