Extending Code Field 20 -> 40

bLuBbLuB Member Posts: 7
Hello,
we have an internal discussion where I need your advice.

As long as I develop NAV changing fieldlength is always a thing where you have to think about alternatives for this.
I would change the field and search all related fields and functions and so on ..

BUT a collegue wants to do this by exporting all objects as text and replace ALL Code[20] fields to Code[40]. ALL Code fields.

What I need from the best community is pros and cons for this approach. I'm absolutely against this.
So correct my standing or tell me why this is a bad idea. I need some good arguments.


Best Answer

Answers

  • NavSolutionNavSolution Member Posts: 36
    its not helping you if passing field in parameter ,cause name is not same as field.
  • bLuBbLuB Member Posts: 7
    Extending fields and find where those fields are used in parameters is not easy but its possible. Have done this multiple times. But extending the Code20 to Code40 means. that you have Item No. with Code40 GL-Accounts with Code40 ..........
    Neverending story which is just a overhead and absolutly not a nice way of development imo.
  • NavSolutionNavSolution Member Posts: 36
    bLuB wrote: »
    Extending fields and find where those fields are used in parameters is not easy but its possible. Have done this multiple times. But extending the Code20 to Code40 means. that you have Item No. with Code40 GL-Accounts with Code40 ..........
    Neverending story which is just a overhead and absolutly not a nice way of development imo.

    You are right but if there is Requirement for this thing then you must to do that right.
  • mohana_cse06mohana_cse06 Member Posts: 5,503
    this is where the problem starts.
    we as experienced NAV people need to explain customer what problems will occur with such requirements.
    this is what I refer whenever such requirements arise
    https://dynamicsuser.net/nav/b/singleton/posts/increasing-field-lengths-in-navision
  • bLuBbLuB Member Posts: 7
    this is where the problem starts.
    we as experienced NAV people need to explain customer what problems will occur with such requirements.
    this is what I refer whenever such requirements arise
    https://dynamicsuser.net/nav/b/singleton/posts/increasing-field-lengths-in-navision

    yes that the thing you have to be really aware. But also if there are problems with extending fields (and those are problems we can fix) I believe it's so much better to go the approach of checking the relations and params and so on before replacing everything from Code20 to Code40.

    The question here is not if it's smart or easy to extend fields. The question was how to do it.
  • AKAK Member Posts: 226
    If you can't avoid doing it, you have to do it by using a "where used tool". Otherwise you will miss every function where the field is passed as a parameter or returned and every variable which is supposed to store values from that field. The approach of you colleague is therefor very silly and will create even more problems.
  • RockWithNAVRockWithNAV Member Posts: 1,139
    If you doing this or your custom added fields then I will suggest go ahed but doing this for standard fields is something which you shouldn't actually because you literally cant even anticipate what wrong could happen and eventually it may turn out to be a nightmare rectifying this.

    Still if it's that utmost urgent then you can do this in test DB and put it in under consideration for 1 month where all transactions and business process should happen. You will get the picture.
  • YuryYury Member Posts: 59
    <joke>Great issue! Really great!</joke>
    I understand issues like "change all "Description" fields lenghts to 150..", but this one is really funny. Sorry...
    But now seriosly. Ask youself "Why do we need it?" Write "+/-" arguments and think a little. Could your specific problem be solved another way?
    In my 15+ years NAV experience opinion, such issues are waste of time. And in 80% of cases - consultant/architect/developer/analyst incompetence.
    Regards,
    Yury
  • KeptyKepty Member Posts: 54
    There are some reasons why we had to change the text/code length in the past
    - Customer name is too short and due to Czech law, we need to print complete register name of the company (and the fields are too short)
    - Some of the item identifiers (like lot number) are too short for some specific goods like medicaments or pills (and it is necessary to track this due to laws)
    Tomáš Kapitán
  • KeptyKepty Member Posts: 54
    What? Search description for the Lot number? It doesn't make sense... You need the Lot number of medicaments in all transaction and you have to track expiration dates of Lot numbers before you make any warehouse movements etc... It is impossible to create a new field because of complexity - it so easier to change field length.

    And customer name? We have some customers with the legal name with 120 characters. And what to do with this? Split the name to Name and Name 2 is not enough. Creating a new field for this is too complex because you have to propagate this new field to all vat reports, documents, etc...
    Tomáš Kapitán
  • bLuBbLuB Member Posts: 7
    Kepty wrote: »
    What? Search description for the Lot number? It doesn't make sense... You need the Lot number of medicaments in all transaction and you have to track expiration dates of Lot numbers before you make any warehouse movements etc... It is impossible to create a new field because of complexity - it so easier to change field length.

    And customer name? We have some customers with the legal name with 120 characters. And what to do with this? Split the name to Name and Name 2 is not enough. Creating a new field for this is too complex because you have to propagate this new field to all vat reports, documents, etc...

    Mostly we have to extend Serial and Lot No. we need to full functionality of this but with bigger size.
Sign In or Register to comment.