Introduction
Personalization refers to changes that a user can make to certain artifacts in the ERP Cloud application on the user interface. These changes can be made to apply for a specific user or for all users accessing the applications. Personalization can be used to change properties of fields such as changing its width. A user can also redesign multiple aspects of using a composer-based personalization. Personalizations are done using the sandbox; all the changes done through personalization remain only to the user who has the activated sandbox, until the sandbox is published, and it will not be visible to any other user.
For example, a user can rearrange certain objects on a page, add and remove designated content, or save queries. A user can add other content to this page or change the order of the current content.
Personalization can also be done on the basis of roles and users. For example, a field on a form can be made visible only to users having a specific role. Expression language can be used to perform user- or role-based personalizations.
Groovy scripts can also be used to perform personalizations for different objects on ERP cloud pages.
Problem definition
Payables
Clients require an approval workflow for payments. Hence, there is a requirement for two sets of users in Payment Workflow (given below):
· Payment Creators: Employees who can only create a Payment Process Request (PPR) but cannot authorize it for final payment
· Payment Approvers: Employees who can only authorize the PPR created by Payment Creators but not create PPRs
Oracle constraints
· Oracle does not support payment approval workflows
· Job roles available in Oracle:
- Accounts Payable (AP) Supervisor: Can create a PPR and authorize it
- AP Manager: Can edit/stop/authorize the PPR submitted by the AP Supervisor
According to client requirement, the AP Supervisor should only create the PPR and not authorize it, but seeded AP Supervisor role has the access to authorize PPR.
Expenses
Reimbursement currency selection on the expense report should be enabled only for one user in the company. It should be read only for the rest of the users in the company.
Oracle constraint
Oracle either allows reimbursement currency selection to be enabled for all the employees or none of the employees in the organization.
Fixed assets
A bulk of asset addition transactions are created through interface with payables module or project module and these transaction are approved in their respective origination system, so can do without approval in the fixed asset module. However, the client needs transactions such as financial adjustments—cost changes, asset life changes, and depreciation method changes—to be approved before being completed in the system.
Oracle constraint
There is no approval workflow capability delivered out of the box for any of the fixed asset transactions.
High-level solution
Payables ( Note this is delivered functionality in R13)
Create a custom role which is a duplicate of AP Manager Role. On the Review Proposed Payments Screen (Payment Authorization Screen), hide the “Review Proposed Payment” button for payment creators via role-based personalization. This button will only be visible to Payment Approvers/users assigned to the custom AP Manager role.
Expenses
User-based personalization using expression language is used to make the Reimbursement Currency selection enabled only for one user in the company who is part of the top management.
Fixed assets
Role-based personalization, along with groovy scripts, is used to customize the asset transaction pages to simulate a simple two-step approval process.
Solution details
Payables
Role-based personalization: A custom role is created based on seeded AP Manager Role. On the Review Proposed Payments Screen (Payment Authorization Screen), the “Review Proposed Payment” button is hidden for payment creators via role-based personalization. This button will only be visible to Payment Approvers/users having custom AP Manager role.
Hide the Review Proposed Payment Button for Payment Creators and make it visible only to the Payment Approvers.
Outcome:
“Review Proposed Payment” screen as visible to Payment Approver. “Resume Payment Process” button is enabled.
“Review Proposed Payment” screen as visible to Payment Creator. “Resume Payment Process” button is disabled.
Other personalizations done to make the solution completely workable.
1. Making the PPR Template mandatory on the “Payment Process Request” screen, so that users are unable to submit the PPR without entering the template.
2. Making the checkbox "Review Proposed Payments" and “Review installments” as read only on the “Payment Process Request” screen, so that these checkboxes are always checked, and payment will also stop for review to the user.
Expenses
User-based personalization using expression language is used to make the Reimbursement Currency selection enabled only for one user in the company who is part of the top management.
#{securityContext.userName!='abc@xyz.com'}
Fixed assets
A workaround for the lack of approval workflow can be achieved using a combination of role-based personalization and groovy scripts.
There are two seeded roles available in Fixed Asset—Asset Accountant and Asset Accounting Manager for each asset book. The solution is designed such that a user with the Asset Accountant role for a particular asset book would create a financial adjustment transaction in that book but will not be able to submit it. Then, a user with the Asset Accounting Manager role for that book would review that transaction and submit it for processing, thus creating two steps in the transaction flow and allowing more oversight for financial adjustments to assets.
Using groovy scrips with role-based conditions, the submit button on the adjustment transaction is disabled for any user with the Asset Accountant role. He can only create a transaction and save it. The submit button is enabled only for users with the Asset Accounting Manager role.
This role-based personalization of the asset adjustment transaction pages can be done through groovy scripts.
The logic used in groovy scripts is—if the user is a manager of current transaction book and input value is not ‘FINANCIAL,’ then the Submit button would be enabled.
The actual script is
#{securityContext.userGrantedPermission['permissionClass=oracle.adf.share.security.authorization.MethodPermission; target=FA_SELECT_ASSETS_FOR_FIXED_ASSET_MASS_TRANSACTIONS_PERMISSION;action=invoke'] &&((((securityContext.userInAllRoles['FA_ASSET_ACCOUNTING_MANAGER_JOB_MLP CH CHF'] && bindings.BookTypeCode.attributeValue=='MLP CH CHF') && bindings.MassTransactionTypeCode.inputValue == 'FINANCIAL') || bindings.MassTransactionTypeCode.inputValue != 'FINANCIAL') && bindings.ReadOnlyFlag.inputValue != 'Y'}
Transaction flow post application of personalization
A financial adjustment transaction flow after applying the personalization is depicted below. This flow considers mass adjustment transactions.
Log into the system using a user ID that has a role of Asset Accountant for a particular book. The user ID should not have access to Asset Accounting Manager role for that book.
Navigator Asset > Adjust Asset > Mass tab. Click on “+” icon to create a new transaction.
Enter the book and transaction type “Depreciation Rules” and click Next button.
On the ‘Enter Mass Depreciation Rules,’ enter Batch Name and Asset Selection Criteria. Then, enter Depreciation Rules Details. Submit button is not available. Click on Save and close.
Log out from the system from the top left hand corner dropdown. Log into the system using a user ID that has a role of Asset Accounting Manager.
Navigator Asset > Adjust Asset > Mass tab. Search for the batch. Open it, Review the details. Submit button is now available. Click on Submit.
Log out from the system and log in using a user ID that has a role of Asset Accountant.
The Asset Accountant should be able to download the transactions in a spreadsheet and complete it as usual.
Business benefits
The personalizations described in this white paper have helped client achieve the below benefits.
· In Payables, client’s indispensable requirement about payment approvals can be resolved using personalization and segregation of duties. This helps them avoid processing of unauthorized payments.
· In Expenses, we can cater to client’s requirements of enabling certain users to select reimbursement currency on expense reports while disabling that option for the rest of the users, thus making the expense transactions more efficient.
· In Fixed Assets, client is able to achieve a workaround for the approval workflow for financial adjustment transactions. This helps them have more control over transactions, avoid errors, and streamline the overall process.
·
Conclusion
The requirements described above are only examples of the Oracle ERP Cloud’s limitations. Personalization is an easy-to-use tool which can be used to make minor tweaks to transaction pages resulting in major efficiency improvements across multiple modules so as to meet some of the client’s critical requirements.