Different behavior Page vs. Form

rsaritzky

Hi all,

I'm doing what I think is a simple modification to the Item Journal - require a "Reason Code" to be entered.

I added one line to the bottom of the OnInsert trigger of the Item Journal Line table:

JnlLineDim.LOCKTABLE;
LOCKTABLE;
ItemJnlTemplate.GET("Journal Template Name");
ItemJnlBatch.GET("Journal Template Name","Journal Batch Name");

ValidateShortcutDimCode(1,"Shortcut Dimension 1 Code");
ValidateShortcutDimCode(2,"Shortcut Dimension 2 Code");
ValidateNewShortcutDimCode(1,"New Shortcut Dimension 1 Code");
ValidateNewShortcutDimCode(2,"New Shortcut Dimension 2 Code");
DimMgt.InsertJnlLineDim(
  DATABASE::"Item Journal Line",
  "Journal Template Name","Journal Batch Name","Line No.",0,
  "Shortcut Dimension 1 Code","Shortcut Dimension 2 Code");

CheckPlanningAssignment;

[color=#FF0000]//Start - Require Reason Code on Adjustment Transactions
IF ("Entry Type" = "Entry Type"::"Positive Adjmt.")  OR ("Entry Type" = "Entry Type"::"Negative Adjmt.") THEN
  TESTFIELD("Reason Code");
//Finish[/color]

On the Item Journal FORM, this works fine - if the "Reason Code" is left blank, a message is displayed, and I can go back and fill in the "Reason Code" and continue.

However, on the PAGE, if the Reason Code is left blank, the message is displayed.

THEN, if I go back and enter a Reason Code, the same error message is displayed along with a second error message:

First message: "Reason Code must have a value in Item Journal Line Journal Template=ITEM,...."
Second Message:"This field cannot be validated since the key fields are valid"

I cannot "escape" or "exit" from this error condition at this point. I have to delete the entire line and start over.

Is a validation of this type discouraged or disallowed in Page objects? I know that a lot of validation is done in the Posting codeunits, but it seems like this one relates to the Item Journal Line record itself and not of related records, and therefore it is a legitimate rule to put in the table itself.

Has anyone encountered something like this? Solution?

Screenshot of the error messages:


Thx

Ron

rhpnt

The first rule of NAV programming is: "Do not interrupt/break the insert,modify or delete trigger!"

skulla

When you see error in RTC press f5 to clear errors then correct them. Otherwise you will see "This field cannot be validated since the key fields are valid" and you can notice in your attachment that it will displays errors as 1 \2 if you try to do any validation without clearing first error.

rsaritzky

Thanks! I'll try that...

Ron

Belias

rhpnt wrote:

The first rule of NAV programming is: "Do not interrupt/break the insert,modify or delete trigger!"

and also...in this case it's pointless to add an error in the oninsert trigger.
a user can always insert a line of type sale, and after inserting it (w/o reason code), change the type to positive adjustment. Game over.
It's better for you to move the error in the posting routine, as the standard nav do (runcheck function of codeunit 21 should be fine)

rsaritzky

Belias wrote:

and also...in this case it's pointless to add an error in the oninsert trigger.
a user can always insert a line of type sale, and after inserting it (w/o reason code), change the type to positive adjustment. Game over.

A "creative" user can many times find a way to "bypass" a required field. NAV has many of these "holes." However, I would think that a user would just enter a reason code rather than go through the hassle of entering a different line type and then changing the line type along with other fields on the line necessary when changing the line type from Sale to Pos/Neg adjustment. Plus, adding the same validation code to the OnModify trigger would take care of this issue.

I understand the philosophy of putting certain validation logic in the posting routine. However, there are a number of validations already done in the table before insert, so I don't necessarily agree with the idea of "don't mess with the OnInsert trigger." To me, I look at the type of validation. In my opinion, the types of validations done in the posting routine are mostly/usually validations related to other tables, for example, if fields on the posting group record RELATED to the item record aren't complete. And the main issue I was concerned with is why the page behaves differently from the form.

Thanks for the insight though - I learn quite a bit from contributors like you.

Ron

beran

One of the difference you see between the page and forms is that you on a page can continue to change more fielde s despite errors in other fields. This is introduced to make it more usuable but it does make the understanding for the app. dev more confusing - as this thread shows. BUT seen from an app. dev perspective it should be considered to be one change at a time. However...

seen from a client perspective it looks as follow - let us call it the client validation scheme or with the nick-name 'clothesline' as I will explain below.
If a field change fails in the validation trigger the server reverts the request but the client notes the failure on a 'clothesline' . The user can then go and change another field that is then send to the validation trigger on the server. Two cases can now arise
1. The change succeeds and the server returns to the client with the all new changes in the currect record. The client now takes down a note (or one of the notes) on the clothesline and tries to send that to the server. And we now get to two sligtly different cases
1.a. The change succeds and we react like 1.
1.b. The change fails and then we try the next on the 'clothesline'. If we have checked all on the 'clothesline' we stop. If any is succeed we start from scratch.
2. The change fails and the server reverts its state and return to the client. The client now make another note of failure on the 'clothesline'.

What happens with failures on the key field changes? (related to this thread). When the user steps out of a key field it tries to save the record. If that fails it brings the record in a blocking mode - when the user change any other field it goes directly to put a note on the clothesline and you see the "This field cannot be validated since the key fields are NOT valid'. Making the key valid the validation scheme kicks in - takes an item down from the 'clothesline' and go on like 1.a/1.b.

rsaritzky

Thanks Eric - so pressing F5 has the effect of as you say "Making the key valid the validation scheme kicks in..."?

Ron

beran

No F5 does not kick in the key validation scheme - it stays in 'validation blocking' mode. Your only option is to close the page unless you know the right way to make a valid key.

By the way if you really want to see the validation scheme kick in then do the following:
0. Use the demonstration company 'Cronus...'.
1. Click 'Create new sales order'
2. Go from 'No.' to 'Sell-to-Customer No.' (which creates the key)
3. Make 'No.'= 10000 and go tab.
4. Goto 'Type' in the 'Lines'
5. Choose 'Type' = Item
6. In 'No' - type 'Linda' and go tab. You now get 'Item No. 'LINDA' does not exist. Missing Member.'
7. Go back to 'Type' and make it 'Resource' and go tab
Now the screen flickers a bit and everything ends up fine.

rsaritzky

So your information about the "clothesline" is very interesting/informative, so I'll hope you'll continue this thread so I can understand a little better. I'd like to try to map my example into your explanation:

seen from a client perspective it looks as follow - let us call it the client validation scheme or with the nick-name 'clothesline' as I will explain below.
If a field change fails in the validation trigger the server reverts the request but the client notes the failure on a 'clothesline' . The user can then go and change another field that is then send to the validation trigger on the server. Two cases can now arise
1. The change succeeds and the server returns to the client with the all new changes in the correct record. The client now takes down a note (or one of the notes) on the clothesline and tries to send that to the server. And we now get to two slightly different cases
1.a. The change succeeds and we react like 1.
1.b. The change fails and then we try the next on the 'clothesline'. If we have checked all on the 'clothesline' we stop. If any is succeed we start from scratch.
2. The change fails and the server reverts its state and return to the client. The client now make another note of failure on the 'clothesline'.

a. The TESTFIELD that I added to the in the OnInsert Trigger on the Item Journal Line causes the client to note the failure on the "clothesline".
b. The only change that I make (without pressing F5) is to correct the field that is blank.

Shouldn't that result in scenario 1a?

What is the effect of pressing F5 on the "clothesline"

Thx

Ron

beran

The InsertTrigger is only affecting the 'clothesline' if it is called in a validate field trigger.
As for F5 then it is not affecting the 'clothesline' - it is the opposite the F5 is blocked indirectly by items on the 'Clothesline'.

Roelof

I'm receiving the same error message: 'This field cannot be validated since the key fields are valid'.
I'm calculating a unit fee field on the Item card. This Unit Fee field is linked to a function on the page/form.
In the function it is checking if the Unit Fee is zero or not. If zero then it needs to send an error on screen and the user shouldn't be able to exit out of the page/form or go to another record (added conditional error in 'OnInsert Record' and 'OnModify Record' triggers).
The functionality works fine in Classic in NAV 2009x, except for build NAV 2009 R2, 33154.
Any ideas?