Things that MS should revisit for future NAV

generic

Almost in every project that I see there are several major issues that causes grief in implementations.

1. Serial, Lot No
2. Costing
3. Reservation/ Item tracking
4. Dimension
5. MRP
6. Lot and serial tracking in warehouse.

The code in these areas are sometimes not follow able.
This is due to afterthought feature added to product. Shortcomings in IDE and scripting language or simply bad design.


Please when moving NAV to Dynamics, please do not move these implementations. While we are far from that, please re-implement these features in future NAV.

I would like to know what common things that cause greaf in your implementation/ modification.

idiot

Revise Navision such that it becomes web-based.

generic

I am looking at CU 22 and value entry "Cost per Unit" gets assigned, changed, reassigned. For example

In some places you see code
ValueEntry."Cost per Unit" := ValueEntry."Cost Amount (Actual)" / ValueEntry."Valued Quantity";



in another location you'll see code such as
ValueEntry."Cost Amount (Actual)" := ValueEntry."Cost per Unit" * ValueEntry."Valued Quantity";


Spaghetti code.

MS please create separate value entries for each costing method /Entry type.

generic

I would also add that Data Migration is another issue.


There is no standard dataports that users can modify to fit their file structure, so everybody has written their own one.

They reuse them in newer version, and if there is a change well they don't know until it' too late.

RIM toolkit doesn't work for transactional data.

kapamarou

I like this topic... =D>

1) I don't like the fact the Master Tables Have Blob fields (Picture...) Has anyone ever used a Picture in "G/L Account" :?:


2) A code example... It seems wrong to me but please share your opinion...

In table 37 Sales Line, we have:

Type - OnValidate()


TestJobPlanningLine;
TestStatusOpen;
GetSalesHeader;

TESTFIELD("Qty. Shipped Not Invoiced",0);
TESTFIELD("Quantity Shipped",0);
TESTFIELD("Shipment No.",'');

TESTFIELD("Return Qty. Rcd. Not Invd.",0);
TESTFIELD("Return Qty. Received",0);
TESTFIELD("Return Receipt No.",'');

TESTFIELD("Prepmt. Amt. Inv.",0);

Since a failure in a TESTFIELD will result in an ERROR and a break of the operation then why have the first 3 commands (or some of them ) in the beginning :?:

Alex_Chow

idiot wrote:

Revise Navision such that it becomes web-based.

They had a chance with NAV2009. I'm not sure why they insist on making a 3 tier structure if the Pages are not web based...

ara3n

Alex Chow wrote:

idiot wrote:

Revise Navision such that it becomes web-based.

They had a chance with NAV2009. I'm not sure why they insist on making a 3 tier structure if the Pages are not web based...

well with 3 tier you can scale the application. And have a web front end as well.

The issue with just being web based is that using web for data entry sucks.

Alex_Chow

ara3n wrote:

The issue with just being web based is that using web for data entry sucks.

Do you think that the current pages sucks less?

ara3n

At least they can improve that or change it. With being web front end, you have to follow web standard.

ara3n

One thing that should be rewritten is get rid of Tracking Specification

Allow Item journal to post with just serial no and Lot No. fields.

Alex_Chow

ara3n wrote:

At least they can improve that or change it. With being web front end, you have to follow web standard.

I still don't think it's necessary to have pages. It doesn't add any significant improvements other than "it looks better".

If you want it to be highly customizable, the classic client will do wonders. For remote and traveling users, the web version will be more useful.

ara3n

Alex Chow wrote:

ara3n wrote:

At least they can improve that or change it. With being web front end, you have to follow web standard.

I still don't think it's necessary to have pages. It doesn't add any significant improvements other than "it looks better".

If you want it to be highly customizable, the classic client will do wonders. For remote and traveling users, the web version will be more useful.

The problem with the classic client is that forms upgrade are hard.
You can't personalize them without modifying them

The classic client wasn't build for sql. The scripting language wasn't build for SQL.
Users could do bad things like removing filters on ILE.
etc, etc. We need to move from classic client.

I don't need talk about development environment.

This is the perfect way to do it. And no matter how much you'll argue that 2 tier is better than 3 tier, I would have to disagree.

ara3n

This is just the begging of pages.

I'm sure just as the classic at the begging had very few features, the Pages will slowly get new features.
This is a major step in moving old clients/ code/ vertical into the right direction.
Just think of possibilities.

Right now we are compiling our code to code in .NET c #.
Once classic no longer is supported, NAV programming possibilities in a new dev environment environment will be much better than what we have now.

ara3n

kapamarou wrote:

I like this topic... =D>

1) I don't like the fact the Master Tables Have Blob fields (Picture...) Has anyone ever used a Picture in "G/L Account" :?:


2) A code example... It seems wrong to me but please share your opinion...

In table 37 Sales Line, we have:

Type - OnValidate()


TestJobPlanningLine;
TestStatusOpen;
GetSalesHeader;

TESTFIELD("Qty. Shipped Not Invoiced",0);
TESTFIELD("Quantity Shipped",0);
TESTFIELD("Shipment No.",'');

TESTFIELD("Return Qty. Rcd. Not Invd.",0);
TESTFIELD("Return Qty. Received",0);
TESTFIELD("Return Receipt No.",'');

TESTFIELD("Prepmt. Amt. Inv.",0);

Since a failure in a TESTFIELD will result in an ERROR and a break of the operation then why have the first 3 commands (or some of them ) in the beginning :?:

The reason is that when the use entered the type field the code below clears the record

init;

So before clearing the record you want to make sure that it's not an order that is partially processed.

ara3n

kapamarou wrote:

I like this topic... =D>

1) I don't like the fact the Master Tables Have Blob fields (Picture...) Has anyone ever used a Picture in "G/L Account" :?:

Nav by Default does not extract the blob data when it retrieves the data. So overhead is minor.
out of 60K companies out there somebody is probably using it and if you are removing the field, you'll have to create a new table to store the data.

I guess you could create a table called Pictures.

PK "Table ID",
PK "No.",
PK "Line No."
Picture as blob

And remove all the picture fields fields.

idiot

kapamarou wrote:

Since a failure in a TESTFIELD will result in an ERROR and a break of the operation then why have the first 3 commands (or some of them ) in the beginning :?:

Oh stop using TESTFIELD already! Have something more meaningful such as
"IF AAA THEN ERROR(someErrorText)"
TESTFIELD is for developers to test the value & is not meaningful for endusers who will see "XXX must be YYY in ZZZ" which does not help them to pinpoint the problematic area.
Imagine the amount of effort saved where the user can correct the error themselves without need to contact technical persons.

generic

Seeing Code in Adjust cost like for example this in CU 5895, makes my stomach cringe.

  IF AvgCostRndgBuf."No. of Hits" > 42 THEN
    EXIT(FALSE);

I guess the developer have some sense of humor and knows the meaning of live.

kapamarou

ara3n wrote:

kapamarou wrote:

I like this topic... =D>

1) I don't like the fact the Master Tables Have Blob fields (Picture...) Has anyone ever used a Picture in "G/L Account" :?:

Nav by Default does not extract the blob data when it retrieves the data. So overhead is minor.
out of 60K companies out there somebody is probably using it and if you are removing the field, you'll have to create a new table to store the data.

I guess you could create a table called Pictures.

PK "Table ID",
PK "No.",
PK "Line No."
Picture as blob

And remove all the picture fields fields.

Indeed I would prefer a separate table. In my opinion it causes some even minor overhead that could be avoided. But I don't delete the field. I just disable it...

idiot wrote:

Oh stop using TESTFIELD already! Have something more meaningful such as
"IF AAA THEN ERROR(someErrorText)"
TESTFIELD is for developers to test the value & is not meaningful for endusers who will see "XXX must be YYY in ZZZ" which does not help them to pinpoint the problematic area.
Imagine the amount of effort saved where the user can correct the error themselves without need to contact technical persons.

You're right. I have had some occasions where I had to change the TESTFIELD into some other error message. But my main point is that either way, checks performed on that record should be happening as earliest as possible to avoid useless execution of code...

idiot

kapamarou wrote:

...
You're right. I have had some occasions where I had to change the TESTFIELD into some other error message. But my main point is that either way, checks performed on that record should be happening as earliest as possible to avoid useless execution of code...

This is especially true when there are dimension errors when attempting to post.
The Posting No. is already assigned & leaves a gap when someone else posts successfully.
Auditors always question why a smaller Posted Sales Invoice No. has a later Posting Date than the next Posted Sales Invoice.
Also explain "Document Deleted"...

kine

Why there are Pages? Because they are the way t multiple "Display targets" without need of any change in the object. You can develop display target for Mobile, for Web, for "Terminal" if you want. You only need to make correct transformation of the XML to target display and you are done. This is not possible with the Classic client which is strongly connect to one display target (and just do not forget the problems when you have smalled LCD than the developer had... ;-). Of course, there are some CONS, but they are everywhere...

David_Singleton

generic wrote:

...when moving NAV to Dynamics, ...

:-k can you explain what you mean by this?

DenSter

generic wrote:

Seeing Code in Adjust cost like for example this in CU 5895, makes my stomach cringe.

  IF AvgCostRndgBuf."No. of Hits" > 42 THEN
    EXIT(FALSE);

I guess the developer have some sense of humor and knows the meaning of live.

All that this accomplishes is that the code doesn't fall into an endless loop, it's actually quite a good way to catch that. Nobody ever gets to 42 levels, so it is a fair assumption that when it DOES get there, it's not a good situation. There's similar constructs in MRP where it only goes 50 levels deep into the BOM structure, a level that it never gets to if you set up your BOM's properly.

I don't get why that is so bad, just because someone typed it as actual code? So properties are not bad? What if they had a variable with 42 dimensions, and it would do something like FOR i := 1 TO ARRAYLENGTH(MyVariable)? would that make it better because they didn't program the actual number? IMHO it only makes the code harder to read, for no good reason other than being able to say you didn't "hard code" any value. It's the same thing as defining a text variable with a certain length. If you apply the 'generic code' to everything consistently, you would not have ANY fixed attributes, and everything gets set based on set up. This obsessive aversion against "hard coding" is sometimes unrealistic, these statements are actually instrumental in making the code more accessible and easier to read.

generic

David Singleton wrote:

generic wrote:

...when moving NAV to Dynamics, ...

:-k can you explain what you mean by this?

when all the 4 ERPs become one. I know it's far away in future, but it'll happen.
It may become two products, enterprise and standard.

Denster


My point is that NAV software has aged to point where rewrite of certain areas is needed. Some code have been touched so many times that has turned into spaghetti.
Features have been added that never part of original design.

DenSter

generic wrote:

My point is that NAV software has aged to point where rewrite of certain areas is needed.

But you used a two line snippet that does not support that assertion. There is absolutely nothing "aged" about that snippet of code. In fact, you didn't assert any of the sort, all you said that "your stomach cringes when you see code like that", without even saying what was so aweful about it.

If you want to make a point, use real arguments, and don't imply that the whole system is rotten just because you found a tiny little snippet that IN YOUR OPINION is not good code. If you want to make a case for things that can improve, point to things that can improve, and tell us what you think should be done to get there, don't just point at something and make a face at it without stating what is wrong with it.

DenSter

generic wrote:

I know it's far away in future, but it'll happen.

Says who? This is old news, Microsoft has repeatedly stated that this is not the way of the future anymore, there are no plans to merge all Dynamics into one product, that is just plain and simple false information.

generic

Real argument. My first post mentions the 6 areas that not only complex but horribly done.

I'll start with Serial and Lot.

This feature was added in 3.x and has been buggy till 5.0 sp1.
Every implementation that I've had, and customers that had lot or serialized items, would have problems with the system, and I would waste countless hours on an undocumented efffft up design.
The posting routine calls a freaking form to call a function in it.
I've see orphaned entries in almost every version. It is virtually impossible to know how records were inserted in reservation entry table. There is virtually ZERO documentation on how to fix it.

In almost every area that wasn't designed properly, NAV has compensated with lots of code.
All this does is complicating the application, and NAV is supposed to be designed with KISS methodology.

For example what is the relationship between serialized Sales Invoice Line and Item Ledger? Have you looked at that table structure?

generic

DenSter wrote:

generic wrote:

I know it's far away in future, but it'll happen.

Says who? This is old news, Microsoft has repeatedly stated that this is not the way of the future anymore, there are no plans to merge all Dynamics into one product, that is just plain and simple false information.

Look at NAV 2009 and every other Dynamics product, they are all morphing, Right now GUI only, but next will the technology, (something .NET instead of scripting language.
And then will be the table structures.

It doesn't make sense to keep 3 small to middle business ERP system around.

As far ms statement, they've stated that they will supported the software till year X and develop it further.
and that develop further means to develop it into one product.

DenSter

generic wrote:

and that develop further means to develop it into one product.

No actually it doesn't, and they have stated this over and over the past few years. They have admitted that the concept of project green is not a realistic goal, and they have abandoned it in favor of different products. You'll find binaries and concepts that are shared, but the base products are and always will be vastly different in many areas. IF there is ever a single product, then it is not something that any of the existing products could morphe into, because the structures are too different to realistically think you could do it. This imaginary product would be completely new. Maybe its technology would be based on one of the existing products, but it would for sure be a new product.

You are making assumptions that are based on absolutely nothing but wildly unfounded speculation.

AdamRoue

Also Micrsoft would struggle with the drop in teh revenue stream - 4 distinct into 1 does not lead to any growth.

As stated, the originally proposed merger will not happen, at least not in the immediate future, and never at the generalistic level originally discussed. That said common approaches will be taken, but the software is fundamentally different, and is not in direct competition in many areas of the world and therefore it actually makes sense to leave them alone, and despite the required resource is seen as being more cost effective overall.

kine

Previous week I "asked experts" on Convergence in Copenhagen abut that (project green, merging the products etc.) and the answer was "no, the products are developed as separate products and right now there is no plan to "merge" them together"...

generic

kine wrote:

Previous week I "asked experts" on Convergence in Copenhagen abut that (project green, merging the products etc.) and the answer was "no, the products are developed as separate products and right now there is no plan to "merge" them together"...

This is the marketing answer right now so that Competition would not use it against the product.
MS still want to sell the Software.

They understood that implementing the project green wouldn't be possible, and if it was built, you would have another ERP, and they have already too many of them. I am not confusing one Dynamics product with project green.

That's why they are implementing the One Dynamics ERP in waves. The first wave is MAKE the UI the same. And that has already happened. Most prospects can't tell the difference between the products.

Next they will move the Business logic/ scripting language into .NET
And after that will be table structures.