Feature Request

2»

Comments

  • p.willemse6p.willemse6 Posts: 216Member
    What also would be nice, are some functional features.

    For example, some of the most frequently used localisations in 1 database. For us, that would be Benelux, Germany and UK in 1 database.

    Almost every company we currently service has several offices abroad, which seems to become a trend. Merging and maintaining all those localisations costs a lot of money. Setting up different databases is sometimes possible, but not always...

    Or a real workflow solution...
  • NavStudentNavStudent Posts: 399Member
    bbrown wrote:
    NavStudent wrote:
    DenSter wrote:
    And that is a problem how? If I have a few customers here in my area, and they have something in common that I can resell to other companies in my area, why should I have to think about making that ready for all the other localizations?
    Because MS is pushing NSC to become vertical and have a solution.
    MS doesn't want to built a complete solution. They build the minimum or less.

    And this approach differs from other mid to upper level accounting system, how?

    How is it different? One is an actual product that works with all areas in the system. The other is a paper lounch.
    my 2 cents
  • bbrownbbrown Posts: 3,095Member
    NavStudent wrote:
    bbrown wrote:
    NavStudent wrote:
    DenSter wrote:
    And that is a problem how? If I have a few customers here in my area, and they have something in common that I can resell to other companies in my area, why should I have to think about making that ready for all the other localizations?
    Because MS is pushing NSC to become vertical and have a solution.
    MS doesn't want to built a complete solution. They build the minimum or less.

    And this approach differs from other mid to upper level accounting system, how?

    How is it different? One is an actual product that works with all areas in the system. The other is a paper lounch.

    I think you are confusing "Add-ons" with "Vertical Market Solutions"
    There are no bugs - only undocumented features.
  • fredefrede Posts: 80Member
    Hi,

    just my comment from Denmark.

    Here we have Celenia who is programming both the payment-add-on in DK and the e-invoice solution.

    You have to install both - and cannot create the fields yourself because the field no's are in "protected" areas.

    So it IS a problem and makes an update a head ache that it shouldn't be.

    Also you have to wait for the update from the add-on before you are able to update!

    And Celenia refuse to build the two solutions in one database-version because they have so many versions to maintain!

    So I understand NavStudent when he points to that problem with Add-ons.

    That is also the main reason why we - at my 2 NAV sites - not have chosen a vertical. If you do so, you are no longer working with NAV but with the vertical provider!

    Don't know if it is the same with other ERP products - but even if it is - it does make it a good point for the customer.
    Regards,

    Henrik Frederiksen, Denmark
  • hrillo666hrillo666 Posts: 9Member
    Fetaures? From the client?

    A way to see sessions without being logged in. Customer calls and asks me something, there are no more licenses so I can't login to see what the problem is. They may very well offer to buy new licenses on the spot, but with Commerce being what is is, we can't really wait for three months for a new license when they are having a problem now, so the immediate solution is to throw people out who are idleing their sessions: BUT there is no way to ses sessions without being logged in. Since there is no sane reason for that, my feature request is that the client can display a list of active sessions without being logged in.
  • ara3nara3n Posts: 9,232Member
    On sql they can run a SP_who and see the list and issue a kill on the ID


    On native, well native won't be supported down the line.

    one more reason they can move the sql if they are not on sql.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • themavethemave Posts: 1,058Member
    My feature request would be if they are going to force us to abandon the native database, can they at least make SQL run a fast and require as little maintenance.

    so, if you don't want to do anything but use Navision, you arn't trying to integrate other programs ect. put some tools to allow a small shop to actually run their business without being a sql expert.

    we have been using Navision since version 2.0 in 1999, native database.

    the total number of times I have done database maintence or optimization is zero.

    I expanded the database once to accomadate the upgrade to 4.0, since it doubled my database size overnight. But otherwise we don't worry about running Navision, we just concentrate on running the business. but it appears if we want to ever upgrade Navision, we are going to have to spend a lot more time on computers and less time on running the business.
  • hrillo666hrillo666 Posts: 9Member
    ara3n wrote:
    On sql they can run a SP_who and see the list and issue a kill on the ID
    Well, usually the accounting assistant I'm trying to assist doesn't have direct access to SQL Server or the fluency in SQL required to make that a fast option, and if they do have an IT-department it takes forever to get them to do anything. In other words, move the existing Sessions field to a place where you can see it without logging into a specific Nav database would make the traditional "Hey Bob, close down Navision for two seconds while I'm on the phone with Support..."-solution work very efficiently indeed. I know, not life or death but a pet peeve To me it's like putting a rearview mirror in a car somewhere you can't see it from the drivers' seat.
  • hrillo666hrillo666 Posts: 9Member
    themave wrote:
    My feature request would be if they are going to force us to abandon the native database, can they at least make SQL run a fast and require as little maintenance.
    That's a double edged sword. Performance vs Simplicity.

    They are however close to make it runnable without any knowledge of SQL Server. If they just tweaked the unattended setup scripts as well as the auto-generated application role's permissions a and made a dialog in the client to handle configuration of SQL Server backup schedules you could have a management free version of Dynamics NAV running on SQL 2005 Express without knowing anything about how the stuff works in the background. Oh and performancewise, SQL Server beats the native database since about 4.0SP3.

    Of course on the other end of the spectrum there are limitations in terms of security in major installations and there are humongous benefits that could be reaped in terms of security if they abandoned support for SQL Server 2000 and just based everything on 2005.
  • Saint-SageSaint-Sage Posts: 92Member
    I would like to see a basic object type that can be modified much like the table editor to create structures I can access in code.

    So in my code I could declare a variable called tempObject which is of a type object, I can then edit the properties of this object and add an Integer called ObjectID, or whatever.

    That way when you are populating and keeping track of data in code, you don't have to have a specific table, because alot of times you don't have a table that matches your datastructures exactly, and you don't want to have to hijack the company information table or something so sloppy as a temp table to stick a bunch of values in that don't really match the variable names in the existing table.

    No one loves you like the one who created you...
  • bbrownbbrown Posts: 3,095Member
    Saint-Sage wrote:
    I would like to see a basic object type that can be modified much like the table editor to create structures I can access in code.

    So in my code I could declare a variable called tempObject which is of a type object, I can then edit the properties of this object and add an Integer called ObjectID, or whatever.

    That way when you are populating and keeping track of data in code, you don't have to have a specific table, because alot of times you don't have a table that matches your datastructures exactly, and you don't want to have to hijack the company information table or something so sloppy as a temp table to stick a bunch of values in that don't really match the variable names in the existing table.

    Yes, it would be nice to be able to declare the structure of a temporary table. Like you can in T-SQL
    There are no bugs - only undocumented features.
  • BlackTigerBlackTiger Posts: 1,221Member
    How about to introduce "NText" data type to manage unicode texts?

    I think it's a lot simpler than to rewrite entire NAV to be "unicodeable".
    "You can’t just ask customers what they want and then try to give that to them.
    By the time you get it built, they’ll want something new.” Steve Jobs
  • KeithMMooreKeithMMoore Posts: 59Member
    I read through this thread quickly so perhaps it was mentioned but 2 items that we would find very useful:

    1. Memo fields - seems to me that the product should be able to make use of what SQL already has in available datatypes

    2. Wiki-Style Help - Since Company Notes disappeared in 5.0, there needs to be a way for end-users to be able to have contextualized help, where business process notes can be easily attached alongside the product documentation.
  • ara3nara3n Posts: 9,232Member
    BlackTiger wrote:
    How about to introduce "NText" data type to manage unicode texts?

    I think it's a lot simpler than to rewrite entire NAV to be "unicodeable".

    Are there any plans for navision for Unicode in future?
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • gaspodegaspode Posts: 19Member
    I seem to remember reading in the What's New: Developing Solutions for Microsoft Dynamics NAV 2009 White Paper that the new XMLport object will support UTF-8 and UTF-16 XML formats.
    Woof!
  • ara3nara3n Posts: 9,232Member
    gaspode wrote:
    I seem to remember reading in the What's New: Developing Solutions for Microsoft Dynamics NAV 2009 White Paper that the new XMLport object will support UTF-8 and UTF-16 XML formats.

    5.0 already supports utf-16
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • BlackTigerBlackTiger Posts: 1,221Member
    ara3n wrote:
    BlackTiger wrote:
    How about to introduce "NText" data type to manage unicode texts?

    I think it's a lot simpler than to rewrite entire NAV to be "unicodeable".

    Are there any plans for navision for Unicode in future?

    Are you asking me? I'm not even MVP... Or you're asking Microsoft? :)
    "You can’t just ask customers what they want and then try to give that to them.
    By the time you get it built, they’ll want something new.” Steve Jobs
  • BlackTigerBlackTiger Posts: 1,221Member
    ara3n wrote:
    gaspode wrote:
    I seem to remember reading in the What's New: Developing Solutions for Microsoft Dynamics NAV 2009 White Paper that the new XMLport object will support UTF-8 and UTF-16 XML formats.

    5.0 already supports utf-16

    You sure? Where?
    "You can’t just ask customers what they want and then try to give that to them.
    By the time you get it built, they’ll want something new.” Steve Jobs
  • ara3nara3n Posts: 9,232Member
    BlackTiger wrote:
    ara3n wrote:
    BlackTiger wrote:
    How about to introduce "NText" data type to manage unicode texts?

    I think it's a lot simpler than to rewrite entire NAV to be "unicodeable".

    Are there any plans for navision for Unicode in future?

    Are you asking me? I'm not even MVP... Or you're asking Microsoft? :)

    Anybody else MVP, MS, Partners, People who came from convergence.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • ara3nara3n Posts: 9,232Member
    BlackTiger wrote:
    ara3n wrote:
    gaspode wrote:
    I seem to remember reading in the What's New: Developing Solutions for Microsoft Dynamics NAV 2009 White Paper that the new XMLport object will support UTF-8 and UTF-16 XML formats.

    5.0 already supports utf-16

    You sure? Where?

    It's just for xmlports, you can change the encoding to UTF-16.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
Sign In or Register to comment.