i want to set the workin date as a "posting to" date so if they intentially select the future work date then only they can do the posting otherwise the system should not accept further data of working date.
Hi Jai,
Why do you want to restrict user for future data entry? What are your requirements when restricting user for data entry?
Sure, setting up the Roles and Permissions can perfectly do the job. But sometimes, like in my current project, one might want to prevent users from modifying the master data and posted data outside the business logics of the application model.
To do this I just put an ERROR('') in every OnInsert, OnModify, OnDelete and OnRename triggers of the specified tables. The codes for every transactions must go then through the functions like NewRec, ModifyRec and DeleteRec which are written for every table in the application model.
I know this is not the standard Navision coding and your future codes using these functions won't be as fast and easy. Hence, the strength of C/AL in Navision is that you can make a transaction almost everywhere you want to. This is my way to avoid future data inconsistencies and also to prevent developers from socalled cowboy- and spaghetti codings.
I hope this might help you.
Chuong Dinh
Comments
Have you tried Roles and Permissions?
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
pleaes suggest.
Jai Verma
Why do you want to restrict user for future data entry? What are your requirements when restricting user for data entry?
Sure, setting up the Roles and Permissions can perfectly do the job. But sometimes, like in my current project, one might want to prevent users from modifying the master data and posted data outside the business logics of the application model.
To do this I just put an ERROR('') in every OnInsert, OnModify, OnDelete and OnRename triggers of the specified tables. The codes for every transactions must go then through the functions like NewRec, ModifyRec and DeleteRec which are written for every table in the application model.
I know this is not the standard Navision coding and your future codes using these functions won't be as fast and easy. Hence, the strength of C/AL in Navision is that you can make a transaction almost everywhere you want to. This is my way to avoid future data inconsistencies and also to prevent developers from socalled cowboy- and spaghetti codings.
I hope this might help you.
Chuong Dinh
http://www.BiloBeauty.com
http://www.autismspeaks.org