I haven’t had a chance to publish a new post lately but last week my client asked me to personalize the Master Supplier Form. So here’s a new post on Forms Personalization for the Supplier Form.
While looking into the best solution for my client, I came across a few posts with what seemded at a first glance a good solution, but somehow these didn’t work for me. So this triggered me to writing a post on this particular solution for my clients’ business requirment. Here are the details:
My client wanted to personalize the Suppliers master and details form. The requirement was that if a particular supplier is of a particular type (e.g. ‘Vendor’), then for a particular responsibility all the fields should be non-updateable and non-insertable, while the form should remain updatable and insertable for other responsibilities. The first condition was that in the Classification tab of the Supplier master form if the value of the the list of values (lov) ‘Type’ is of a particular kind, both the master form and the details form (Supplier sites) should be non-updateable and non-insertable, while it should remain updatable and insertable for other responsiblities. Another condition wass that in the Classification tab of the Suppliers master form, a particular responsibility would only be allowed to select a limited number of values from the list of values (lov) normally available within the field ‘Type’. In other words if a query on po_lookup_codes would normally yield say 10 values, the selection should be limited to say 5 values. Other values should remain invisible for a certain responsiblity. A third requirement was that in the Classification tab of the Suppliers master form the list of values (lov) should be made mandatory.
Here is the solution for these requirements:
Navigate to and open the Suppliers window using the Purchasing SuperUser responsibility
Enter the Form Personalization form.
(M) Help > Diagnostics > Custom Code > Personalize
Rule Seq: 10 Description: Make the whole Suppliers Form non-updateable when Vendor type is ‘Vendor’
Trigger Event: WHEN-NEW-RECORD-INSTANCE
Trigger Object: VNDR.VENDOR_NAME_MIR
Condition: ${item.VNDR.VENDOR_TYPE_DISP_MIR.value} = ‘Vendor’ Processing Mode: Both
Context:
Responsibility: set the value to your responsibility.
Select the Actions tab
Actions Seq: 10
Type: Property
Language: All
Object Type: Block
Target Object: VNDR
Property Name: UPDATE_ALLOWED
Value: FALSE
———————————————
Actions Seq: 20
Type: Property
Language: All
Object Type: Block
Target Object: VNDR
Property Name: INSERT_ALLOWED
Value: FALSE Repeat the above actions for each block in the Supplier Form (VNDR, VNDR_USES, SITE, SITE_USES and CONTACTS).
Of course to make the form updatable and insertable for other responsibilities you must make a new rule sequence and repeat all of the above, but instead set the value to TRUE instead of FALSE. Save your work, return to the Condition tab and we will now define a second rule to cover the second requirement.
Rule Seq: 20
Description: Limit Selection Vendor Type LOV for authorisation XYZ
Trigger Event: WHEN-NEW_BLOCK-INSTANCE
Trigger Object: leave empty Condition: leave empty
Processing Mode: Not in Enter-Query Mode
Context: Responsibility and set the value to your responsibility.
Select the Actions tab
Actions Seq: 10
Type: Builtin Language: All Builtin
Type: Create Record Group from Query
Argument: SELECT displayed_field ,description ,lookup_code FROM po_lookup_codes WHERE lookup_type = ‘VENDOR TYPE’ AND SYSDATE < NVL (inactive_date, SYSDATE + 1) AND lookup_code IN (‘VENDOR’, ‘EMPLOYEE’) ORDER BY UPPER (displayed_field)
Group Name: XX_VENDOR_TYPE_GRP
———————————————
Actions Seq: 20
Type: Property
Language: All
Object Type: LOV Target
Object: VENDOR_TYPES
Property Name: GROUP_NAME
Value: XX_VENDOR_TYPE_GRP
Save your work, return to the Condition tab and we will now define the third rule to cover the last requirement.
Rule Seq: 30
Description: Make the field ’Type’ mandatory
Trigger Event: WHEN-NEW-RECORD-INSTANCE
Trigger Object: VNDR
Condition: leave empty
Processing Mode: Both
Context:
Responsibility: set the value to your responsibility.
Save your work, exit all forms and test your personalization. The reason some other posts didn’t work for me was that they used WHEN-NEW-ITEM-INSTANCE for making the blocks non-updatable and non-insertable and that in other posts limiting the LOV was made using a message and using a message and a Builtin to raise a form trigger failure. I found that limiting the record group was a much neater way of limititing the number of values. I hope this helps some of you.
Personalize the Master Suppliers Form
I haven’t had a chance to publish a new post lately but last week my client asked me to personalize the Master Supplier Form. So here’s a new post on Forms Personalization for the Supplier Form.
While looking into the best solution for my client, I came across a few posts with what seemded at a first glance a good solution, but somehow these didn’t work for me. So this triggered me to writing a post on this particular solution for my clients’ business requirment. Here are the details:
My client wanted to personalize the Suppliers master and details form. The requirement was that if a particular supplier is of a particular type (e.g. ‘Vendor’), then for a particular responsibility all the fields should be non-updateable and non-insertable, while the form should remain updatable and insertable for other responsibilities. The first condition was that in the Classification tab of the Supplier master form if the value of the the list of values (lov) ‘Type’ is of a particular kind, both the master form and the details form (Supplier sites) should be non-updateable and non-insertable, while it should remain updatable and insertable for other responsiblities. Another condition wass that in the Classification tab of the Suppliers master form, a particular responsibility would only be allowed to select a limited number of values from the list of values (lov) normally available within the field ‘Type’. In other words if a query on po_lookup_codes would normally yield say 10 values, the selection should be limited to say 5 values. Other values should remain invisible for a certain responsiblity. A third requirement was that in the Classification tab of the Suppliers master form the list of values (lov) should be made mandatory.
Here is the solution for these requirements:
Navigate to and open the Suppliers window using the Purchasing SuperUser responsibility
Enter the Form Personalization form.
(M) Help > Diagnostics > Custom Code > Personalize
Rule Seq: 10 Description: Make the whole Suppliers Form non-updateable when Vendor type is ‘Vendor’
Trigger Event: WHEN-NEW-RECORD-INSTANCE
Trigger Object: VNDR.VENDOR_NAME_MIR
Condition: ${item.VNDR.VENDOR_TYPE_DISP_MIR.value} = ‘Vendor’ Processing Mode: Both
Context:
Responsibility: set the value to your responsibility.
Select the Actions tab
Actions Seq: 10
Type: Property
Language: All
Object Type: Block
Target Object: VNDR
Property Name: UPDATE_ALLOWED
Value: FALSE
———————————————
Actions Seq: 20
Type: Property
Language: All
Object Type: Block
Target Object: VNDR
Property Name: INSERT_ALLOWED
Value: FALSE Repeat the above actions for each block in the Supplier Form (VNDR, VNDR_USES, SITE, SITE_USES and CONTACTS).
Of course to make the form updatable and insertable for other responsibilities you must make a new rule sequence and repeat all of the above, but instead set the value to TRUE instead of FALSE. Save your work, return to the Condition tab and we will now define a second rule to cover the second requirement.
Rule Seq: 20
Description: Limit Selection Vendor Type LOV for authorisation XYZ
Trigger Event: WHEN-NEW_BLOCK-INSTANCE
Trigger Object: leave empty Condition: leave empty
Processing Mode: Not in Enter-Query Mode
Context: Responsibility and set the value to your responsibility.
Select the Actions tab
Actions Seq: 10
Type: Builtin Language: All Builtin
Type: Create Record Group from Query
Argument: SELECT displayed_field ,description ,lookup_code FROM po_lookup_codes WHERE lookup_type = ‘VENDOR TYPE’ AND SYSDATE < NVL (inactive_date, SYSDATE + 1) AND lookup_code IN (‘VENDOR’, ‘EMPLOYEE’) ORDER BY UPPER (displayed_field)
Group Name: XX_VENDOR_TYPE_GRP
———————————————
Actions Seq: 20
Type: Property
Language: All
Object Type: LOV Target
Object: VENDOR_TYPES
Property Name: GROUP_NAME
Value: XX_VENDOR_TYPE_GRP
Save your work, return to the Condition tab and we will now define the third rule to cover the last requirement.
Rule Seq: 30
Description: Make the field ’Type’ mandatory
Trigger Event: WHEN-NEW-RECORD-INSTANCE
Trigger Object: VNDR
Condition: leave empty
Processing Mode: Both
Context:
Responsibility: set the value to your responsibility.
Select the Actions tab
Actions Seq: 10
Type: Property
Language: All
Object Type: Item
Target Object: VNDR.VENDOR_TYPE_DISP_MIR
Property Name: REQUIRED
Value: TRUE
Save your work, exit all forms and test your personalization. The reason some other posts didn’t work for me was that they used WHEN-NEW-ITEM-INSTANCE for making the blocks non-updatable and non-insertable and that in other posts limiting the LOV was made using a message and using a message and a Builtin to raise a form trigger failure. I found that limiting the record group was a much neater way of limititing the number of values. I hope this helps some of you.
Viewed 16682 times by 3852 visitors
Related posts: