Extending Code Field 20 -> 40

bLuB
bLuB Member Posts: 7
in NAV Three Tier
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

  • NavSolution
    NavSolution Member Posts: 36
    its not helping you if passing field in parameter ,cause name is not same as field.
  • bLuB
    bLuB 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.
  • NavSolution
    NavSolution 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_cse06
    mohana_cse06 Member Posts: 5,506
    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

    -Mohana
    http://mohana-dynamicsnav.blogspot.in/
    https://www.facebook.com/MohanaDynamicsNav
  • bLuB
    bLuB Member Posts: 7
    mohana_cse06 wrote: »
    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.
  • AK
    AK 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.
  • RockWithNAV
    RockWithNAV Member Posts: 1,172
    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.
    Thanks

    Blog - rockwithnav.wordpress.com/
    Twitter - https://twitter.com/RockwithNav
    Facebook - https://facebook.com/rockwithnav/
  • Yury
    Yury 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
  • Kepty
    Kepty 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
  • Kepty
    Kepty 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
  • bLuB
    bLuB 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.

Categories