Here is a template that I usually work from to programmatically implement effective-dating for a field. Usually PeopleTools automatically takes care of effective-dating, however there are certain situations in which this does not occur. Eg. when clicking on a hyperlink or button that then modifies a non-derived record-field on the page.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
If Not (GetRow().IsNew) Then Evaluate %Mode When %Action_UpdateDisplay When %Action_UpdateDisplayAll /* In Update/Display mode, only allow the update of future dated rows */ If TABLE.EFFDT.Value > %Date Then /* Allow the user to update field */ Else /* Not a future dated row. The user should not be allowed to update field. */ Error MsgGet(15, 1, "Message Not Found"); End-If; Break; When %Action_Correction /* When in Correct History mode, allow the user to update field. */ End-Evaluate; End-If; |
This particular scenario can be written more succinctly as shown below:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
If Not (GetRow().IsNew) Then Evaluate %Mode When %Action_UpdateDisplay When %Action_UpdateDisplayAll /* In Update/Display mode, only allow the update of future dated rows */ If TABLE.EFFDT.Value <= %Date Then /* Not a future dated row. The user should not be allowed to update field. */ Error MsgGet(15, 1, "Message Not Found"); End-If; Break; End-Evaluate; End-If; |
It all depends on your requirements. I usually start from the template and then re-structure as I see fit.
In summary, this logic ensures that a user will only be able to edit a field on an effective-dated page when any of the following criteria is met:
– The row has been newly inserted
– The row is future dated
– The context is Correction mode.