THAT's the point

Captain_DX4

Savatage wrote:

Well we didn't switch because we thought "Hey we have too many people".
It was not the intention of becoming a smaller dog with bigger bite

Manpower enhancements never came into mind - it was much more about competing in the marketplace. Telling a vendor or customer "with our new system...Yeah, we can do what you want or need!"

And of course it is usually sold as "Be more productive and profitable with your existing staff," yes? *hehe*

themave

Captain DX4 wrote:

themave wrote:

What would be really helpful is if there was a way to tell if there were only cosmitic changes made, not code changes. then the code could be upgraded leaving the display layout un-changes.

I completely agree! And if in v5 we can get some functionality like ASP where there is created the different layers of code (Presentation layer apart from Functional layers), then that would work very nicely for us!

I am afraid v5 is moving in the opposite direction, it seems that the whole wysiwyg form design is going away and will become you set priority on fields and the software makes the form layout based on that priority, which will in affect take away making forms look just the way you want, instead you will be able to say what you feel is important and Microsoft will in affect decide how you really want it displayed.

Savatage

Doing our own customizing of forms by moving fields around or showing/hiding fields and reports was a huge selling point for us. It's sounding like Ver 5 or higher will be much more difficult for an end-user to make changes easily.

If the people who implimented our software saw it today it would be unrecognizable to them

We didn't change anything in G/L Only O:)

The ability for the end-user to make the system more user friendly by themselves is a great thing - That's the point!

DenSter

themave wrote:

What would be really helpful is if there was a way to tell if there were only cosmitic changes made, not code changes. then the code could be upgraded leaving the display layout un-changes.

There is a way to tell, if you know what you're doing. My whole point before was that if you have a report merged by someone who knows what they are doing, you can easily merge the changes. The reason why it is impossible to tell how long any given report will take is that you can't see all the code when you open it, and you have to do a compare of the text object to estimate the upgrade time.

But.... if all you did was make the odd control a little bigger, that shows up as a pattern to someone who knows how to 'read' the objects during the compare, and it won't be too hard to keep those changes, especially if you tagged the changes.

themave

DenSter wrote:
But.... if all you did was make the odd control a little bigger, that shows up as a pattern to someone who knows how to 'read' the objects during the compare, and it won't be too hard to keep those changes, especially if you tagged the changes.
Interesting, as an end user, I don't have access to cal/code on forms, and I can not export the fob as text file, anyway I could tag changes I make?

I would definitely take the time to do that.

has it stands now for forms, I take a screen shot of how I want it, and then just re-do everything, we make no changes on forms to cal/code.

Now reports, most of those changes are only cosmetic, but when I do change cal/code, I //comment the start and end of my changes

And rather then delete of change existing code, I //comment it, and make my code below it

Miklos_Hollender

David Cox,

yeah, I think your're right, and some other rumours I've heard:

- Service Management was originally custom development for a small company

- Manufacturing was developed by a company called Lanham. I assume it must have originally been an industry solution, a vertical. I mean when I showed it to f.e. beer brewsers they didn't like it at all but when I've showed it to car part manufacturers they expressed considerable interest.

These might explain some things.

The original reason I opened this topic is:

1. I think Navisison can be considered good compared to the ERP industry at large.
2. But the ERP industry just SUCKS.
3. Now we are having kind of serious evidence on 2)

But I don't mind if the topic is going to other directions, get on with it, OK. That's fine. I just wanted to tell these are my original ideas for opening this topic.

Captain_DX4

I think this has been a great thread so far. Lots of variations of how people are considering the industry and NAV and what we consider requirements for base and customization. I always find value in learning other people's perspectives and internally challenging my own. Keeps me a better developer in this game!

Captain_DX4

Miklos Hollender wrote:

- Manufacturing was developed by a company called Lanham.

I'm fairly certain that Lanham developed the Advance Distribution components of NAV back in the v2.x days, and someone else developed the Manufacturing. Lanham's current add-on products have more synergy with distribution, so I couldn't see them developing manufacturing. That just isn't their strength...

DenSter

Lanham's work was the basis for a lot of the warehouse functionality in NAV. The manufacturing bit was written by a German solution center.

Kowa

One customer uses all 20 characters in their item nos, but does not need the UOM ( = redesign all reports and documents). Others use only 5 but need a third description field,
( = redesign all reports and documents), the next one needs more than 8 address fields (which again means redesigning all documents as well as extending the formatting functions). One needs the contact address instead of the Ship-to address, the next one the opposite, but not if it is a credit memo, then he expects this address to be blank, so that the driver can fill it in when he picks the items up. No matter how much you put into a software, sooner or later you will hear about something missing. "I expected this to be part of the standard". The problem is, "this" is usually something nobody has ever requested before.

A standard software like Navision can't cater for every need that might occur, it can only provide a sound basis that can relatively easy be pulled into shape. As long as two similar structured companies have a totally different way of running their business ( which happens all the time), it is quite impossible to make these two happy "out of the box".

There are accepted ( or compulsory) accounting principles, but no principles whatsoever how to run a business. That is why developing ERP Software is a wearisome task as soon as you leave the G/L.

themave

Kowa wrote:

One customer uses all 20 characters in their item nos, but does not need the UOM ( = redesign all reports an documents). Others use only 5 but need a third description field,
( = redesign all reports and documents), the next one needs more than 8 address fields (which again means redesigning all documents as well as extending the formating functions). One needs the contact address instead of the Ship-to address, the next one the opposite,but not if it is credit memo, then he expects this address to be blank, so that the driver can fill it in when the picks the items up. No matter how much you put into a software, sooner or later you will hear about something missing. "I expected this to be part of the standard". The problem is, "this" is usually something nobody has ever requested before.

A standard software like Navision can't cater for every need that might occur, it can only provide a sound basis that can relatively easy be pulled into shape. As long as two similar structured companies have a totally different way of running their business ( which happens all the time), it is quite impossible to make these two happy "out of the box".

There are accepted accounting principles, but no principles whatsoever how to run a business. That is why developing ERP Software is a wearisome task as soon as you leave the G/L.

Ok, I keep hearing that all customers want different things, which I totally agree with, and it is one reason I picked Navision in the first place. Because we could change things.

But I would also say, which many have agreed to, the standard reports are pretty poor, I would also say, that if you are going to have a standard report, the design of the report should not be sub-standard, which is the case with the inventory reports I brought up. I feel if the decision was made to put the item no on a report, then the logical follow on should be to show the entire Item no. Not try to put additional fields which would cause the existing ones to be cut off.

I don’t feel you should try to design a standard report to fit every need, since that would be impossible. But, once you have chosen a field to put on a standard report, you should make sure it will work for all users. Since you know some users will only need to show 10 character, you also know some will need to show all 20. So why design it not to work out of the box for many users, what is the point of designing a standard report you know won’t work for many people.

Savatage

That's a good point. With all the version upgrades & hotfixes & SP, etc it still appears (by reading all these posts) that no time has been spent on the reports.

You would think that by now someone would have addressed that issue. Just by surveying some nav using companies they should be able to assertain "in general" what fields are most needed on a "Sales History" report (for example).

I'm telling you if they spent some serious time on the reports that it would be an additional strong selling point.

I looked a a few of the reports we DON'T use, because they are the only unmodified ones, that it's very very basic. When I look at them I get the feeling "This is what you can kinda do with this report" and everyone has to add in their missing pieces. If this is the case then the "Help" should be outstanding. Not little snipit's here & there.

So they feel incomplete. And they are not always as easy to change, if you don't know what you're doing.

I remeber back in 2003 I spent all day on this great report, it looked good, it had all the info & bells n' whistles - then realized "What! I can't sort it in the order I want! Ahhhh!"

Bought Crystal the next day - still love it

"Instead of coming up with What Are We Going To Do Next, They should fix some of the problems that have been with the system from the beginning. Else these problerms keep finding themselves in the next version. But it appears NON-CODE problems like reports are not considered a problem" That's the point!

I think every post for this topic should end in "That's the point"

David_Cox

Maybe Navision should be shipped with several different report packs, Portrait, landscape, plain, lined, boxed no bill-to address etc: and different layouts, styles, the Customer could purchase a report pack that came close to what they want and just Import and Improve the ones they wanted.

:roll:

Waldo

Well, actually, the NSC could do this quite easily.
We have about 50 report that we provide "standard" with the product. The customer can use all of them. If they still need something else, they can get it with reduction, so we can also add this to our list of available reports for future customers...
:-k

Miklos_Hollender

Happy Holidays!

Now having some spare time for philosophising, I'd once again like to go a bit deeper than these practical issues.

Why is ERP as a culture so outside the IT culture in general?

I mean, other kinds of IT people like web designers, network engineers, Linux enthusiasts etc. are writing blogs which are published on reddit.com, digg.com, and other similar websites which are kind of starting the define the IT culture in general. And just go to reddit.com and search for "ERP", "Navision", "SAP" or something like that - you find almost nothing.

Things are happening so slow. For example, if you just look at the architecture decisions - looking at where MSCRM is, where Navision is going and where SAP is going for a long time with NetWeaver: it seems the next big architectural trend will be SOAP/WSDL-based web services. But if you look at the IT world outside ERP, for example at blogs posted at reddit.com, they all have largely agreed that SOAP/WSDL is too complicated, and the consensus is on a much simpler approach on web services based on REST (REST means that f.e. you have a Customer at http://something.com/customers/11156 and and you query it with a simple HTTP GET, modify it with a HTTP POST, create a new one with a HTTP PUSH and remove it with a HTTP DELETE). When will it trickle down to us? Probably in years, if ever. We are going towards directions they've already came back from. We are kind of outside the general IT culture. Why?

Alex_Chow

You're probably better off starting a new topic.

The answer to your question is, of course, money, time, and resource. It's slow because there are other priorities, budget concerns, and not enough manpower.

Savatage

I think the ERP's aren't so big on blogs is that it's a closed group under strict privacy aggrements where as web designers and linux developers depend on sharing ideas in order to forward their knowledge and expanding thier product to the next level.

I think that's why you can see the speed and progression of say "Web Designs". In this case more cooks do make a better cake. Some of the web pages today are amazing in what they can do compared to just a few years ago.

ERP's can't just throw things together "hopefully" and see if they work. Companies pay a pretty penny that the logic has been double & triple checked for accuracy.

robsmit

All difficult stories above.
Just use C/ODBC it does work properly!!!!
Then MS Access (lousy report interface)
Excel with MS Query does a good job this way. (Stuck with that nice VBA)

And Visual Foxpro excels all the way.

Get a good crafstman or an expensive consultant ;-)

Then you get very nice reports, Navision will never give you.