Stuck while coding

David_Singleton

David Singleton wrote:

By the way, I don't want my comments to be taken as anything derogatory against nverma, I am sure that he/she is doing everything possible to learn Navision and deliver high quality services to the client. My issue is with the management of companies that fail to see the long term benefits of training their Navision consultants and taking on a few high end people to get things moving.

I should also have added...

There are something like 1.4 million Navision users in the world today. A number that could never have been achieved without a solid product and a solid partner network to deliver this product.

We see on the forums a very small percentage of these users having issues like this. The vast majority of partners are very reliable deliver solid services and have very satisfied clients. Unfortunately since my business is all about fixing systems for that very small percent, its sort of a personal issue for me.

So to the 99.99% of partners out there delivering great services and with happy clients, ..."Thank you for giving Navision a great name". :thumbsup:

To the other 0.01% thank you for keeping me employed for all these years.

KYDutchie

Ok Nverma, after this off-topic venting I will return and try and help you.

nverma wrote:

After debugging the code I came to realize that I was trying to modify the record before an insert. That's why the system threw the error message.

I have a quick question for willy I tried to implement what you suggested: it gave me an error at this part

IF CheckFixedAsset THEN
Type := Type::"Fixed Asset"
ELSE
Type := xRec.Type;
CLEAR(ShortcutDimCode);

It kept saying that CheckFixedAsset must be either true or false...then I tried changing the statement to CheckFixedAsset = TRUE (savatage pointed out earlier that writing true would be just redundant...so why did the system throw and error saying the true/false is missing ](*,) )...then it gave me another error saying that you cannot assign a VOID to a boolean...

Does the return Value of the trigger CheckFixedAsset on the Purchase line say boolean? You can check that by going to that trigger, view the local variables and check the return value tab.

nverma wrote:

Chinmoy/Willy - The biggest problem that I had with this particular task was I didn't know where to put the code initially. I mean how did you know that the code will go in OnNewRecord of the form??? What was your through process to determine that, this is the trigger the code will go in...

Willy - Even initially, when you helped me determine how to assign the boolean to true based on the no. series that was selected. How did you know that the code will go in OnValidate trigger. Because when I was initially trying to implement this, I kept trying to find a place to put the code in the No. series table itself. I spent hours trying to debug the no. series table to figure out the exact point where the information would get transfered to purchase line table, I never realzied i was looking at the wrong place to put the code...What was your through process to determine that, this is the trigger the code will go in...

That is where the training comes into play. I had a very good initial training in C\AL programming from Sammy Pinkus.
But I also kept training myself and writing down everything I should know.

Basically, I try to use these 6 simple rules for what trigger to use:
1. if I need to check the value of a field entered by a user or validate a value to the business rules, I put the code in the OnValidate trigger of the field in the TABLE
2. I look at what kind of operation the transaction is performing on the current record and add code to the corresponding trigger in the TABLE
a. Insert -> OnInsertTrigger
b. Modify -> OnModifyTrigger
c. Delete -> OnDelete Trigger
d. Rename -> I try to avoid the OnRename as much as I can.
In these triggers I mostly try to set field values in the table that are related to other tables or set field values in other tables that are related to the current record.
For example, in the OnDeleteTrigger you delete comment lines out of the comment line table that are directly related to the record.
3. Annotate any modification in the the trigger itself and a short description of the modification in the Documentation trigger.
4. For more complex coding of business rules, I like to create a new codeunit and reference it from the table, this way I do not "polute" the Native code to much and that will make upgrades a lot easier.
5. If my Navision Client crashes and shuts down, I am using the wrong trigger. :whistle:
6. TEST YOUR WORK!

90% of my work I spend my time in Codeunits and tables, 10% in other object types.

Hope this helps,

Regards,

Willy

David_Singleton

Code needs only to be added in two places. First in CU415 second in CU90.

David_Singleton

KYDutchie wrote:

90% of my work I spend my time in Codeunits and tables, 10% in other object types.

I sometime think that 90% of my time is spent convincing customer to NOT add code where it is not needed.

dans

David Singleton wrote:

I sometime think that 90% of my time is spent convincing customer to NOT add code where it is not needed.

glad to hear I'm not the only one who feel that way.

Chinmoy

I was going through all the comments, and I feel all are correct in saying that "do not put code where it is not needed". However, there is still something called a "situation". And sometimes it is best to act accordingly. Anyways, no harm meant... conventions need always be followed.. good luck!

jversusj

off topic (like many replies in this thread), but sometimes stock NAV really can't do what the customer needs, and not because a prior ERP could. If you are managing business requirements with an offline spreadsheet or printed guide, crossing your fingers and praying that everything works out, it may be justified to modify NAV.

We have a ton of customer compliance requirements and it drives me nuts how we pollute our NAV environment to comply with one-off things for individual "whale" accounts, but what is the alternative? Having people work outside of the system is better for the health of the NAV objects, but terrible for customer service (and thus detrimental to sales).

Thoughts? We are looking at a reimplementation next year and that is the perfect opportunity to approach some of our past mods from a better position.