Why OnAfterValidate does not work on certain table fields

samantha73samantha73 Member Posts: 43
Hi Guys
I have created a custom field on purchase line table - say U_TaxAmout . Now I want to calculate and update this field when Amount field is validated. However if I modify "Amount" field and use OnAfterValidate trigger, my user field does not get populated. But if I trigger on "Direct Unit Cost" or Quantity it works. Trying to understand why certain fields cannot be used to trigger inserting values to other fields. Does this mean Amount or Amount Including VAT fields do not have triggers?

Best Answers

  • JJMcJJMc Member Posts: 39
    Accepted Answer
    What is happening here is that when the user enter the values in the fileds needed to calculate the Amount field, in the procedure or part of code that calculate the Field Amount, they do not VALIDATE the field. They wrote this code: Rec.Amount := ...... instead of REc.Validate(Amount,.....)
    This way you can write code in the OnBeforeValidate or OnAfterValidate field Amount and you will not have this trigger triggered. Bad pratices... ;-)
  • bbrownbbrown Member Posts: 3,138
    Accepted Answer
    A "bug" or "design flaw" is when the product does not perform the functionality intended by the designer. It is not when it does not do something we think it should do. Intent is a key factor in understanding why something works the way it does.

    Much of the core functionality of the product was designed many years ago. Long before Microsoft was involved or transaction automation became a common thing. The product was designed around the basic idea that a user was sitting at their computer and typing information into a screen (form\page). There are product features that function only thru manual data entry because their logic is on the form\page and not the table(s). One example is the "auto-reserve" functionality.

    Assignments to certain fields are not validated simply because it was not required to deliver the needed functionality.
    There are no bugs - only undocumented features.

Answers

  • JJMcJJMc Member Posts: 39
    Accepted Answer
    What is happening here is that when the user enter the values in the fileds needed to calculate the Amount field, in the procedure or part of code that calculate the Field Amount, they do not VALIDATE the field. They wrote this code: Rec.Amount := ...... instead of REc.Validate(Amount,.....)
    This way you can write code in the OnBeforeValidate or OnAfterValidate field Amount and you will not have this trigger triggered. Bad pratices... ;-)
  • samantha73samantha73 Member Posts: 43
    Thanks makes sense why triggers are not activated on some fields but no idea why MS have := and .validate() on some but not others and whats the logic. Not sure if yu can create your own table triggers on base tables?
  • bbrownbbrown Member Posts: 3,138
    Accepted Answer
    A "bug" or "design flaw" is when the product does not perform the functionality intended by the designer. It is not when it does not do something we think it should do. Intent is a key factor in understanding why something works the way it does.

    Much of the core functionality of the product was designed many years ago. Long before Microsoft was involved or transaction automation became a common thing. The product was designed around the basic idea that a user was sitting at their computer and typing information into a screen (form\page). There are product features that function only thru manual data entry because their logic is on the form\page and not the table(s). One example is the "auto-reserve" functionality.

    Assignments to certain fields are not validated simply because it was not required to deliver the needed functionality.
    There are no bugs - only undocumented features.
Sign In or Register to comment.