THAT's the point

DenSter

themave wrote:

and hope that someday Miklos Hollender gets put in charge of usability at the Dynamic division. :P

:shock: don't even joke about that

themave

DenSter wrote:

themave wrote:

<snip> it has already been identified as the one field in the entire table that unique and the single most import field as all related information ties to it. <snip>

The single purpose of a primary key is to be able to uniquely identify records in the table, it has nothing to do with the 'importance' of the field. With 20 characters you have (assuming that you are using only letters and numbers) 36 (A-Z plus 0-9) to the power of 20 unique values at your disposal, which is more than enough for any system. The only valid reason (IMHO of course ) why anyone would need more than 20 characters is when a customer is coming from a legacy system and they don't want to go through a renumbering during data migration.

You'd be much better off using specific fields for specific purposes, that's much easier to program, filter, report, etc.

Another reason would be that you are in the automotive industry (which I might add is not a small industry) and you use manufactures numbers. which are quite large in many cases. Now we could use the manufacture number in a cross reference or something, but every price disk, every catalog, every parts manual that has been printed for the last 30 years (which we still use, since we service transmissions that old) use the manufacture number. And these numbers are stamps on the parts to identify them, are printed on the boxes when they are received, and on and on and on.

I guess we could use ZFK1345464646 and that represents the manufactures number repl-386-4564-4646-34666-xrg

themave

DenSter wrote:

The single purpose of a primary key is to be able to uniquely identify records in the table, it has nothing to do with the 'importance' of the field.

The single purpose is to uniquely identifythe records in the table.

That kinds of sounds important to me, and one would assume that if that is the one unque identifier, you may want the whole thing to show on a report. so that the next part that is similar and sorts to be right next to it, could be identified on the report as being different.

Savatage

It's just so much is crushed onto one line. :roll:
Spread it out. It's all about the chocolaty goodness inside O:)

Hey MS - I'll redesign all reports!! (for a small fee of course) 8)

We found the orig report to be to messy & unorganized.
http://savatage99.googlepages.com/AR_TEST.pdf

themave

Savatage wrote:

It's just so much is crushed onto one line. :roll:
Spread it out. It's all about the chocolaty goodness inside O:)

Hey MS - I'll redesign all reports!! (for a small fee of course) 8)

http://savatage99.googlepages.com/AR_TEST.pdf

Hey nice report, but I did notice one little thing

your date field doesn't print all the digits

Savatage

Yes that's the only field I DIDN'T change/move/resize.
*I guess that's the perfect example, even the standard date field on some the reports don't fit.

FORMAT(TODAY,0,4) big month!

all fixed now thanks.

Miklos_Hollender

and hope that someday Miklos Hollender gets put in charge of usability at the Dynamic division

That would be funny The end result would be something like that: you turn on your computer, a big window pops up: "Hello, I'm NAV! I've sold 345 PCS of Items on EBay. Some of them demanded some discounts which I agreed to give, is that OK (Y/N)? I arranged the delivery with DHL, they'll be here in 20 minutes to pick them up. Turn on the printer please, so I can print the invoices. I'll notify you when the payments arrived. Press C if you want to use that revenue to change your three years old car for a new one, I'll buy one on Ebay if you choose so. Press N 452 times if you DON'T want 10% of the revenue to transfered to the bank account of Hollender Usability Foundation and expect me to crash much more often then. And now the computer will shut down in 10 seconds.

And now... 5... 4... 3... 2... 1... holiday!

Miklos_Hollender

In Navision's case the primary key is not only a technical identifier but most of the time also the human identifier of the product as well f.e. you put Item No.-s on websites, invoices etc.

It's an ages old trick to use long item numbers as you can save quite a lot of development this way. Say f.e. the 12th digit is 1 if the Item contains phospor and 0 if does not. Wanna know the total sales of products containing phosphor? Filter any standard sales report as ???????????1* . Throw out entries to Excel, break up Item No. with a function and create Pivot tables. Et cetera, et cetera. This way lots of custom development can be saved. It's a very old trick and very useful. This justifies long numbers.

DenSter

themave wrote:

That kinds of sounds important to me

Importance implies an emotion, a subjective quality. It's what defines information out of bits of data. The unique identifier of a record is data, not information. In itself it doesn't say anything about the record. The values of various fields is what actually say something about the record, possibly in combination with values from related records in other tables.

You can look at the number "epl-386-4564-4646-34666-xrg" and not have a clue what it is until you read the description, or the part category. There's a table for this purpose (Item Vendor), although the Vendor Item number is also just 20 characters

Again, I am not trying to trivialize your requirement, I even agree with it to a certain extent. I just wish you would acknowledge why it is the way that it is for valid reasons. If they had put enough room on the report for 20 W's, you would have another complaint about some other field that 'you would expect in every inventory report' not being on there, because all the space was taken up by the Item number.

Then we could argue about why is it not in a bigger size paper, and then you would have the complaint of 'who on earth has a printer big enough for that size paper'. Then we could argue about why is it not in a smaller font, and then you'd have a complaint 'but then everyone needs a magnifying glass to read it', and so on and so on....

DenSter

Miklos Hollender wrote:

This justifies long numbers.

no that is not true. It takes no development at all to filter on a field, but it DOES take development to program it to filter on the 12th character. It is MUCH easier to have individual fields to filter on than to program complex filter strings.

davmac1

This is an interesting discussion.

on upgrades - if someone can figure out how to exclude the user mods from the standard code, so you can upgrade and apply patches like you do with MS Office, then you would earn the gratitude of millions of users and become incredibly wealthy!

Miklos_Hollender

One thought. Actually, small business ERP can be considered a fairly new concept. If you just look back to the early nineties, you had some very basic problems.

For example databases were either expensive (DB2), unreliable (Oracle at that time), or had trouble supporting 30-60 concurrent users (DBASE, or the RAIMA that later on became Navision's native database, although Navision adding FlowFields to RAIMA really helped a lot but the lack of record/page locking was a pain). Affordable, fast and fairly reliable databases came somewhere around 1997-8.

Or, the task of putting a database table on a form which is very easy for us is amazinly hard outside the Navision world. Even today's Delphi or Visual Studio requires suprisingly many boilerplate code to make it really usable (hint: if you have to do this, check out IdeaBlade DevForce). Back that time there was Clipper and FoxPro but the databases used by them weren't suitable for 30-60 users and there was basically nothing else, other than handcoding everything in VB or something like that, which you'd probably rather not do.

So it is reasonable to say that the small business ERP industry (which has almost nothing to do with the old mainframe-based big biz ERP industry) is a new, experimental one. There is nothing wrong with that. Actually I often feel that with the customizations we do now we are kind of laying the foundations for the new standard systems of the 2010's years. Probably this feeling is what makes this kind of job a fun thing to do despite all the problems - in a sense, we are the pioneers, the trailblazers. But then admit it! Admit that it's still experimental. Be honest about it. Vendors should really version current products as 0.8 - they aren't very far now from what a quality-conscious person would call a real production quality but still not there. Don't market them as something "finished" that you just install and ta-da, it solves your problems. If it's experimental, say it openly and then everything is fine.

themave

DenSter wrote:

themave wrote:

That kinds of sounds important to me

Importance implies an emotion, a subjective quality. It's what defines information out of bits of data. The unique identifier of a record is data, not information. In itself it doesn't say anything about the record. The values of various fields is what actually say something about the record, possibly in combination with values from related records in other tables.

You can look at the number "epl-386-4564-4646-34666-xrg" and not have a clue what it is until you read the description, or the part category. There's a table for this purpose (Item Vendor), although the Vendor Item number is also just 20 characters

Again, I am not trying to trivialize your requirement, I even agree with it to a certain extent. I just wish you would acknowledge why it is the way that it is for valid reasons. If they had put enough room on the report for 20 W's, you would have another complaint about some other field that 'you would expect in every inventory report' not being on there, because all the space was taken up by the Item number.

Then we could argue about why is it not in a bigger size paper, and then you would have the complaint of 'who on earth has a printer big enough for that size paper'. Then we could argue about why is it not in a smaller font, and then you'd have a complaint 'but then everyone needs a magnifying glass to read it', and so on and so on....

I understand what you are saying and don't disagree with it. but the underlying assumption you are making is that the programer made the correct decission in not displaying the entire field. Which for some customers he did, and for others he did not.

So the programer had valid reasons and you accept those as valid without know what the reasons are, you have looked at it, and you can see reasons which you feel are valid, when in fact it could also likely be the reasons were laziness on the developers point or maybe not.

But I point to a report in the contact management granule, that I was helping another poster make changes to, the cover letter by defualt prints the banking info on an intro letter to a contact. Now, at one point this may have been important, or maybe not, but in this day and age printing banking info on a generic intro letter to a contact is very inapporpriate. with the privacy and credit fraud concerns. So, was some long ago valid reason for this being there, are was a low paid person in charge of designing reports and put this there. I think that is more likely. I don't think a highly skilled programer designed the reports at all, but instead it was the guy just learning Navision and it was his job to learn on reports.

which gets to the point of my problem, built in reports are not user friendly, they fit very few users out of the box and you have to pay additional to make them usable. and then you have to pay agian, if you want to upgrade.

Savatage

But "That's the way it's done" unfortunatly.

You would think that once a company commits to an upgrade that a few things should be thrown in, like redoing your custom reports.

Most reports that have been customized are needed for the company to continue a smooth working environment. So, as if, the upgrade wasn't enuf $$ now you have to pay to get your busness up and running again as it did before the upgrade.

This hasn't been our businesss plan for the last 20 years - we get the best we can get - use it for 7+ years until we simply can't go on with that package anymore. Then shop for the next great software Package that will last us for the next 7+ years.

We can do heavy modifications in house and It simply will not/nor ever pay off to do every little upgrade. Our next software change will be in about 3 years and if it's NAV again, then great but it's not written in stone.

Scarface."Say Hello to my little friend" := Maintenance Plan + years;

Basically because we haven't made that investment year after year after year on upgrades now we have a bunch of savings to put towards Nav 5 or 6 or whatever and treat it like a new installation.

A new Installation after the 2nd service pack :-# - That's the point!

DenSter

Nobody made a 'correct decision', it was probably more along the lines of 'lets not spend too much time on these reports, they are going to change them anyway' than 'lets have a meeting with our entire design team and come to a conclusion as to what constitutes our best practices policy so that we can serve 80% of our customer base'

The fact is that most, if not all, of our customers customize their reports no matter how nice the existing standard ones are. Now we could argue if that is because they are picky or because the standard reports suck and we would probably both go to the latter. Like I said in my first reply, just consider buying a set of 100 custom reports and get rid of all upgrade problems at once. Most of them will work just like before, and everybody will be happy.

DenSter

Savatage wrote:

Basically because we haven't made that investment year after year after year on upgrades now we have a bunch of savings to put towards Nav 5 or 6 or whatever and treat it like a new installation.

I'm not supposed to say it, but I think that is probably the best way to look at it. Unless of course you need an upgrade for technical reasons, or you can't get new users added to your license because your version isn't supported anymore.... Sheesh when did it get this complicated...

Savatage

Unless of course you need an upgrade for technical reasons, or you can't get new users added to your license because your version isn't supported anymore.... Sheesh when did it get this complicated...

Well you have to be sure that everything is running correctly of course before you take that leap. We waited a good year or two before the ties get cut. and we always plan for a few more licenses "just in case" but frankly since the installation of Nav our # employees have gone way down. What used to take 2 people with Macola now takes 1 with Nav so it's a savings all around. not just in licenses but, healthcare, payroll, insurance, etc etc.

Upgrading for the heck of it doesn't make alot of sence to me - especially if the system runs as you like

That's the Point!

David_Cox

The old Navision developers created granuals for specific Customers, showed these to Navision who then decided that the module would make a good standard Module, like fixed assets which I belive was written by someone for thier Customer then brought into the standard package.
So we have a lot of fields that mean nothing and often wonder why they are there.

Serial Numbers were one to one with the Purchase and Sales lines, then the tracking lines appeared, as one example.

Jobs and Resources is the same as it was 10 years ago, and could be improved and used more, and there a lot of posts wanting navision to talk to Project, but no one seems to have mastered this yet!

Maybe in another version!

Alex_Chow

Hmm... Seems like this thread has gotten so popular after only one day. How things change when you don't log in for a day...

Anywho, there is 50% chance that this research is wrong.
http://www.newscientist.com/article.ns?id=dn7915

Savatage

deadlizard wrote:

Hmm... Seems like this thread has gotten so popular after only one day. How things change when you don't log in for a day... :

How dare you!!

Anywho, there is 50% chance that this research is wrong.
http://www.newscientist.com/article.ns?id=dn7915

A bit off topic - but speaking of funny news stories
http://www.theonion.com/content/node/56641

I love The Onion! That's the point!

DenSter

deadlizard wrote:

Hmm... Seems like this thread has gotten so popular after only one day. How things change when you don't log in for a day...

Anywho, there is 50% chance that this research is wrong.
http://www.newscientist.com/article.ns?id=dn7915

That is funny

Alex_Chow

My post was just to point out that we're all arguing about possbly nothing when another research comes out disprove this research.

Captain_DX4

DenSter wrote:

Miklos Hollender wrote:

This justifies long numbers.

no that is not true. It takes no development at all to filter on a field, but it DOES take development to program it to filter on the 12th character. It is MUCH easier to have individual fields to filter on than to program complex filter strings.

I agree with this perspective. Coding information into a key field is all fine as long as the coding is maintained properly.

However, what happens when another user enters an item and mixes up the coding? How many companies do we know that will have multiple users entering in item codes? Or new users, who get peer training that is not 100% complete. Or worse, new users coming in to replace an existing user and only get a few days overlap to get all the training they need in their position, including how to code these numbers? Or no training at all?

So much can go wrong in schemes such as these that it makes little sense to attempt to maintain it. Using alternative fields with real-language codes and descriptions will be much more valuable for users in any of the above situations to be able to maintain the system most easily.

Captain_DX4

davmac1 wrote:

This is an interesting discussion.

on upgrades - if someone can figure out how to exclude the user mods from the standard code, so you can upgrade and apply patches like you do with MS Office, then you would earn the gratitude of millions of users and become incredibly wealthy!

That would require that every developer of modifications at every solution centre worldwide use the EXACT SAME methods to mark modifications. I'm having enough trouble getting the developer I'm working with to put ANY markings for his modifications whatsoever, let alone a standardized set!!

Nice idea if we could get it. Perhaps in future versions of the product, the IDE itself would remember the original object and automatically mark where the changes are, and then make adjustments for us upon upgrades. That would be nifty!

Captain_DX4

DenSter wrote:

Nobody made a 'correct decision', it was probably more along the lines of 'lets not spend too much time on these reports, they are going to change them anyway'...

*LOL* How true!

DenSter wrote:

<snip>Like I said in my first reply, just consider buying a set of 100 custom reports and get rid of all upgrade problems at once. Most of them will work just like before, and everybody will be happy.

Except I don't always find this the case. In upgrades if the base version changes, won't you also upgrade the customized version? Take a company cheque for instance. How often has the report 1401 changed over the years, which really affects how it works in a financial sense? Wouldn't that necessitate reviewing the code in the custom-range report and bringing forward the same base-functionality enhancements, much the same as if you had customized the base-version report anyway?

In some circumstances, sure. But as a blind "let's do this for every customer," I'm just not seeing the value.

Captain_DX4

Savatage wrote:

<snip> What used to take 2 people with Macola now takes 1 with Nav so it's a savings all around. not just in licenses but, healthcare, payroll, insurance, etc etc.

Oooh! Macola! I haven't heard that one in a while. *hehe*

However, to play devil's advocate, wouldn't that be the same for any ERP over time? We're talking about how time goes on and new functionality is added, it should be more productive usually. Whether we're talking a Macola->Macola jump, or a Macola->Nav jump, the latest of either (providing their still being developed, of course) should include manpower enhancement over the older. Isn't that what every ERP sells? *wink*

themave

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.

This would help with the majority of reports, as most changes I have ever seen involve just making the report look a little different, such as show the whole part number. Most form changes by end users are only cosmitic, because even with the form designer you can not change cal/code, so all you can do is make it look a little different, why for every upgrade or service pack should I have to redo all the forms and reports, when I have changed no code?

Captain_DX4

deadlizard wrote:

Hmm... Seems like this thread has gotten so popular after only one day. How things change when you don't log in for a day...

Anywho, there is 50% chance that this research is wrong.
http://www.newscientist.com/article.ns?id=dn7915

Intersting. Also to consider that most survey's are based on people's perceptions, which are mostly grounded in an emotional response, not necessarily informed or logical choices.

Savatage

However, to play devil's advocate, wouldn't that be the same for any ERP over time? We're talking about how time goes on and new functionality is added, it should be more productive usually. Whether we're talking a Macola->Macola jump, or a Macola->Nav jump, the latest of either (providing their still being developed, of course) should include manpower enhancement over the older. Isn't that what every ERP sells? *wink*

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!"

Unexpected bonus rule! That's the point!

Captain_DX4

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!