Feature Request

p.willemse6

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...

NavStudent

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.

bbrown

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"

frede

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.

hrillo666

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.

ara3n

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.

themave

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.

hrillo666

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.

hrillo666

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-Sage

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.

bbrown

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

KeithMMoore

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.

ara3n

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?

gaspode

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.

ara3n

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

ara3n

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.

ara3n

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.