Purchase status

In Purchase order form , i have a custom field Purchase status with values Created, Approved, Ordered, etc we want to add another option Price Checked… and this status can be updated only by a particular user… how to have this facility… i am new to navision programming… and the above customization was done 3 yrs back with no info now… i want to restrict the option to update this field to Price checked value to only a particular user.

Easiest would be to add a field to the user setup table which you call “Price Check Allowed” or similar. In the onValidate trigger of the field “Price Checked” in the Purch Header Table you just need to GET the user from the user setup table with the USERID global variable and check if this user is allowed to perform a change on that field. If not allowed, just come up with an ERROR.

goto table 38 ( Purchase Header Table on which Purchase Order form is generated),select field “Purchase status” - select properties of this field - find property called “OptionString”- Add your new option “Price Checked” to this end of the options. save the table. goto table 38 ,select field “Purchase status” - goto OnValidate() trigger of this field. Write the following code: If “Purchase status” = “Purchase status”::‘Price Checked’ then begin MemberOf.RESET; MemberOf.SETFILTER(“User ID”,’%1’,’@’ + USERID); Member_of.SETRANGE(“Role ID”, PRICE_CHECKED); IF not MemberOf.FIND(’-’) THEN begin “Purchase status” = xrec.“Purchase status”; Error(‘You do not have permissions to set status to Price_Checked’); end; MemberOf variable should be created its type record and table ame is Member Of. Add a new role called PRICE_CHECKED and assign the role to the users who can change the status to this new status. this is simple solution. also the solution varies according to how the field status is being modifed ( directly in the field, or via function). Thsi solution will work when the field value is changes in the field text box or when onvalidate trigger is called.

Lakshmi, whilst your code is quite correct, and the principle that you suggest will work fine. It is generally rowned upon in Navision to write “hard coded” solutions. By this I mean you should not be writnign code that relies ont he user entering a specific text string to work. It is just asking for problems. thomas’s solution is more generic and safer.

I usually use Lakshmi’s approach, but instead of hardcoding the new role (PRICE_CHECKED) I create a new field in the respective setup table (e.g. Purchase setup) where you configure the name of this role. Very similar to the User table approach, though in my opinion is more consistent with the Navision permission/role philosophy and you handle all permissions issues in one single place. Saludos Nils