Dynamics F/SCM Customer Experience (CRM) Dynamics GP Dynamics Business Central (NAV) Dynamics SL Power Platform Fabric Copilot

[Lewis Rosenberg]

Would you like the item number field in NAV / Business Central to be longer than 20 characters?

Vote here:  Expand Item No. (Number) to 50 chars

Experience Dynamics 365		remove preview
Expand Item No. (Number) to 50 chars On the Item table, the No. field is limited to Text 20. Please extend the length of the Item No. View this on Experience Dynamics 365 >

——————————
Lewis Rosenberg
IT Manager
Mars Fishcare
Chalfont PA
————————————————————————
BCUG/NAVUG All-Star
BCUG/NAVUG Board of Advisors, Chairperson
BCUG/NAVUG Programming Committee

Twitter: @RosenbergL
LinkedIn: https://www.linkedin.com/in/rosenbergl
————————————————————————

NAVUG/D365BC-User Group Focus
May 18-19, 2019
Denver, Colorado
——————————

[Jason Wilder]

How do you vote “No” on the link you provided?   It might be interesting to see the No’s alongside the Yes’s.  Maybe I am missing it.

——————————
Jason Wilder
Senior Application Developer
Stonewall Kitchen
York ME
——————————
——————————————-

[Lewis Rosenberg]

Microsoft only looks for the YES votes to see if there is enough interest in a proposed enhancement to NAV/BC, but you can add comments in favor or against a proposal.  

I can see where this topic can generate some debate and discussion.  Personally, I prefer short item numbers.  They are easier to work with and you can use description, category, dimension fields, etc. to tag the item with more descriptive information for filtering, grouping and reporting.

Unfortunately, many companies like to put lots of meaning behind their numbers and as mentioned in the proposal, it becomes difficult to work with and integrate with other systems when this occurs.

——————————
Lewis Rosenberg
IT Manager
Mars Fishcare
Chalfont PA
————————————————————————
BCUG/NAVUG All-Star
BCUG/NAVUG Board of Advisors, Chairperson
BCUG/NAVUG Programming Committee

Twitter: @RosenbergL
LinkedIn: https://www.linkedin.com/in/rosenbergl
————————————————————————

NAVUG/D365BC-User Group Focus
May 18-19, 2019
Denver, Colorado
——————————
——————————————-

[Nirav Shah]

I have had instances where companies have asked for the capability to add intelligent item numbers that go over 20 characters.  It would be a nice option if necessary.

——————————
Nirav Shah
Solution Architect
To-Increase
——————————
——————————————-

[Devora Locke]

The flip side of this is that when companies have to customize fields to accommodate the longer character strings in an item number, due to requirements from either the customer or the parent company, the process of upgrading becomes more complicated. And we need to be careful not to overwrite our own mods every time we add another one. We’ve had to customize quite a few fields in NAV to fit the way we do business, so have no interest in revisiting that in BC. 

Your mileage may vary <g>
-Devora

——————————
Devora Locke
Shin-Etsu MicroSi, Inc
Phoenix AZ
——————————
——————————————-

[Jason Luchka]

I’d vote No. We try to keep ours at 10. I can’t imagine some poor soul having to key in 50 character item nos.

I’ve had more people complain about the address fields being insufficient, especially for non USA addresses.
The other big complaint is that folks expect to be able to an unlimited number of characters into a field – similar to how CRM works to capture a narrative, instead of breaking it apart into comment lines of X chars each.

——————————
Jason Luchka
Senior Enterprise Applications Analyst
siffron
Twinsburg OH
——————————
——————————————-

[Jason Wilder]

Also a no.  For large companies with millions and millions of records there could be some negative impacts:

• It will take a while to handle this in an upgrade as it expands the field in so many tables
• Will most likely increase the size of the database, could be significant for large databases like ours.  Besides being the Primary key in the Item table, it is a foreign key in tons of tables.  Just doesn’t seem like a small ask to do this.
• All add-ons and custom code will have to be upgraded to use this new field length (this is a pain)
• 20 characters allows for a number that I can’t even imagine (quintillion I think).  Though there may be a few a case for this for a few customers maybe not worth the effort for everybody else.
• Would way rather see the Address fields or Your Reference or External Document No. expanded a little more.

——————————
Jason Wilder
Senior Application Developer
Stonewall Kitchen
York ME
——————————
——————————————-

[Ron Ketterling]

BC now has 100 characters for address fields.

As to a longer part number, I agree that 20 is enough in theory, but many industries (medical is one) adopt the longer part number of the manufacturer since the product is available from multiple sources. Using your own number instead of the manufacturer’s number would increase complexity and probably cost you business because your customers will not see the product number and assume that you don’t carry it.

So, in our experience, a longer part number is required by some industries and cuts NAV out of the picture.

Sent from my T-Mobile 4G LTE Device

Please excuse the brevity of the response and any mistakes.  Thanks. 

——Original Message——

Also a no.  For large companies with millions and millions of records there could be some negative impacts:

• It will take a while to handle this in an upgrade as it expands the field in so many tables
• Will most likely increase the size of the database, could be significant for large databases like ours.  Besides being the Primary key in the Item table, it is a foreign key in tons of tables.  Just doesn’t seem like a small ask to do this.
• All add-ons and custom code will have to be upgraded to use this new field length (this is a pain)
• 20 characters allows for a number that I can’t even imagine (quintillion I think).  Though there may be a few a case for this for a few customers maybe not worth the effort for everybody else.
• Would way rather see the Address fields or Your Reference or External Document No. expanded a little more.

——————————
Jason Wilder
Senior Application Developer
Stonewall Kitchen
York ME
——————————

[Meenakshi Singh]

My vote is NO. I don’t think there is a need to increase it more than 20 characters. Companies should be able to manage the items nos. with 20 characters even UPC and GTIN codes are 12-14 characters. The additional field or search field can be 50 characters and that’s where any additional item no. can be stored.

~Meenakshi

——————————
Meenakshi Singh
Senior Manager, Business Applications
Home Market Foods, Inc.
NAVUG Programming Committee
——————————
——————————————-

[Michael Heatherly]

Companies involved with Process Control Instrumentation often represent manufacturers that utilize product configurators.

The position of a character in that 50 character string signifies a feature or option.

ie: parameters of
Pressure, Temperature, Flow ranges, mounting options , stainless steel, physical dimension etc. It creates a unique SKU #  you need to order under. 
Packing lists coming into the warehouse refer to that part number.

The product call out number should be the primary index inquiry value.

Pricing lists provided by the manufacturer refer to that 50 character per number.

We had o modify all the downstream programs including Lanham Eship.

You might sell 15% of the potential product SKU list. 

You need the 50 character part number capacity to handle the lines.

?

——————————
Michael Heatherly
controller
Lesman Instrument Company
BENSENVILLE IL
——————————
——————————————-

[Kevin Fons]

I am also a NO. 
I am not a fan of “intelligent” part numbers, there are a myriad of other fields in NAV/BC that can be used to add attributes to filter and search.
There is also discussion on increasing the size of the cross reference no field.
I do understand what Michael is saying but have usually use alternate fields to work around this case.
Increasing this would cause every report using the item no field to potentially have to be fixed due to the length change and could also break external integrations.

——————————
Kevin Fons
Senior Application Consultant
Innovia Consulting
waunakee WI
——————————
——————————————-

[Iaroslav Pankovskyi]

Lewis,
Thank you for this discussion. Perhaps, if you could explain why exactly you or your end Users think that they need 50-character No. for Items, our community could appreciate and contribute a vote or an alternative solution instead of just pondering over the topic.

On the same note, one of the ways to satisfy the needs of a customer is to use No. 2 Field on the Item Table – this can be exposed side-by-side with the No. Which means that now Users get twice as long Field on SQuote, SOrder, SInvoice and other Reports with relatively simple modifications.

Yet another way to satisfy some of Users’s needs around long Item No. is to use Automatic Extended Text.

These both solutions have been successfully used in my experience.

Community would also appreciate if you could share your solution or concluding thoughts on the topic.
Good luck with your and your end Users’ objectives.

——————————
Iaroslav
——————————
——————————————-