Item Card. Field "No." Lenght 20 not enough

Hy Everybody, i have a problem. I need to manage Items with Codes longer than 20 bytes. What would you advice? 1) extend the standard field No. lenght of Item Card 2) New Field 3) extend the standard field No. lenght of Item Cross reference 4) Other Thank you very much Luca

Hello! This has been discussed on a number of previous occasions. It is generally agreed that extending the size of the primary key field in this way is not recomended. There is an existing, hidded, field in the Item Table called “No.2”. It is generally recomended that this field is made visisble and used instead of extending the existing No. field.

quote:

this way is not recomended

I agree, I wouldn’t recommend it either, though using other alternatives will always require a lot of adjustments in forms and reports, testing that these modifications fit well into the user procedures, and the respective user training… if you have a running project, with users already trained and all reports already modified, then it might even be “less time intensive” to modify the PK field (Developer Toolkit helps a lot…) Anyway, I think if you use Item Code that are longer that 20 characters (and are not using some kind of barcode or technical help), you should rather review the item naming convention, and implement a more sophisitcated coding scheme - users will be happy to be able to use shorter codes, and will commit fewer “selection” errors… Saludos Nils

I agree. If you are migrating from a system with more than 20 characters, I would add a “Legacy No.” field that can hold the ‘old’ number, and create new numbers in Navision, based on a regular numbering series. Then during data migration you map the transactions connected to the ‘old’ number to the new Navision number.

This is an interesting subject - My first reply would be: Yes it is! I mean - Look into the global world - EAN (European Article Numbering System) ‘only’ allows 13 characters - However you can’t even use all of them, as the first 3 characters are the prefix for origin - now you got 10 left 4 is company - 6 left - and the last character are a calculated value - 5 characters only! (same goes for the US, with the UPC code) The problem you / your customers are having, is due to ‘smart’ numbering - and with so many others, your implementation of ‘smart’ numbers are causing issues - and not solving any problems… I would say - bite the dust - and create new item numbers. What I have done for other clients, is storing the ‘Old Item No.’ - I useally create a cross reference table - for data conversion purposes - and then I store the old item no. in the ‘Search Description’ field. - the reason being - and a lot of people doesn’t know this - when entering Item No (or Customer, Vendor, Job, etc). If a direct hot is not found - Navision tries the same value in the Search Description field - The first hit, will then be selected. : Try it in a Cronus Database - Create a sales Order - don’t look up or type in 10000 - but type in ‘The Cannon’ - and navision will select 10000 - The Cannon Group for you. By storing the old number in the Search Description, you allow the customer to still use their old number, while getting used to the new numbering scheme.

Excellent Henrik! Amazing “undocumented” feature… you never stop learning here! Saludos Nils

Another out-of-the-box-feature is the Item Cross Reference. Just insert a record with the old item no and the users can enter the old item no. in the cross reference no. column in document lines or journals

There is another nice feature in the Item Journals (at least). When entering an item number, the OnAfterInputItemNo function in the CU 240 ItemJnlManagement is called (OnAfterInput). Just change that function to implement additional search algorithm for your longer item numbers and call the same “OnAfterInput” trigger to the fields where you will be using (looking up) item numbers (i.e. Sales, Purchase and Transfer Documents). This enables the user to either enter the “new” (shorter) or the “old” (longer) item number into the same field. Your users will be happy, I guess, as no additional training is needed.

Where to even start. Firstly to Luke, I find it hard to believe that your client has more than 13,367,494,538,843,700,000,000,000,000,000 individual items, so as mentioned above, 20 characters is plenty. Its just up to you as a consultant to now show your cleitn why they pay you, by showing them not only how to write code, but also how to better manage their business. What you need to do is to look at the needs of their business, and see how they can better use the Navision search ability rather than trying to use inteligent part numbers. This is a ver very common request from clients but alway it can be solved without expanding the code length.

Just create a new field and call it “Part No.” and store your long item number in there, then create a key on that field and extend the search functionality of Navision to that. If you do not need to “Search” on the “Search Description” (meaning on the text copied from the description field), you could even change the “Alternate Search Field” property of the item number to your new “Part No.” field. This will give you the advantage to use both numbers in all fields with a table relation to the “No.” field of the item table without changing one line of code at all.

In fact I find the AltSearchField property useless as it is programmed currently. Instead of returning the first record where the AltSearchField begins with the value entered, it should display the default lookup form for that table with the records containing the value entered in their AltSearchField.

quote:

it should display the default lookup form for that table with the records containing the value entered in their AltSearchField

That would be in fact a very desirable “feature”, and customer always keep on asking for that funcionality. Of course, you can inlcude it yourself with the OnLookup trigger in a couple of tables, but it would really be a nice feature.

quote:

as a consultant to now show your cleitn why they pay you, by showing them not only how to write code, but also how to better manage their business

I can only agree, but unfortunately, a client not always accepts that an “external” consultant might tell on how to run their business… and in the end it turns out that he was right tu stick to his experience… or that he should have listened more to the consultant… depends of course a lot on the consultant and his experience aswell [;)] Saludos Nils

Thank you to everybody who replied to my question. I think we will use a new field with a new Key. It could be strange but the need of our Customer is due to the fact that they are in the middle of the supply chain as a pure distibutor and they need to use the Number used by the Vendor to classify their products. So it could be easier to manage the process of purchasing and selling, also because that code is strictly used by our Customer’s Customers…[:)] Luke

In that case the changed “AltSearchField” might help you in all situations (purchase and sales).