This section provides an overview of the required as well as optional steps for implementing the AME Credit Memo Request workflow.
The setup steps that follow provide you with basic credit memo request functionality. To fully leverage the capabilities of Oracle Approvals Management (AME), refer to the Oracle Approvals Management Implementation Guide.
The following setup steps span the following Oracle applications:
In Oracle HRMS:
Confirm that your collectors, salespeople, approvers, and Receivables user are defined as employees in Oracle HRMS.
See: Finding a Person Using the Find Person Window.
The Receivables user is the employee whose approval initiates the creation of the credit memo.
If you want the AME Credit Memo Request workflow to behave similarly to the Credit Memo workflow without AME, then you can:
Create jobs for the approvers in your HR Hierarchy Limits path using approval authority levels.
See: Defining a Job.
Assign a job to each employee who will be an approver in your HR Hierarchy Limits path.
See: Entering an Assignment.
Use the approval authority levels as conditions when defining your AME rules.
In Oracle System Administrator:
Confirm that all collectors, salespeople, approvers, and the Receivables user are defined as users with the appropriate responsibilities.
Attention: When defining users in the Users window, enter the employee name in the Person field. This indicates that the user is also an employee and can receive workflow notifications.
Note: Assign the Workflow User responsibility to all users who should receive workflow notifications.
Set the AR: Use Oracle Approvals Management in Credit Memo Workflow profile option to Yes.
The default value is No.
In Oracle Receivables:
Confirm that your collectors are set up.
See: Collectors.
(Optional) Create additional credit memo creation reason codes, using the CREDIT_MEMO_REASON lookup type.
Set the Tag field to Yes to publish each reason code to iReceivables. When submitting a credit memo request, the requestor can select any reason code that is defined in the system.
(Optional) Define a credit memo batch source for use with this workflow.
Note: Define this batch source only if you want all credit memos generated by the AME workflow to use the same batch source. See: Oracle Workflow Setup.
If, however, you want credit memos generated by the AME workflow to obtain the credit memo batch source from the credited transaction's batch source, then skip this step.
To set up Oracle Workflow:
Map Oracle Workflow's directory service to the users and roles currently defined in your organization's directory repository by constructing views based on those database tables. The Notification System uses these views to send notifications to the approvers specified in your activities. Oracle Workflow provides example directory services views that you can modify and reload.
Your roles can be either individual users or a group of users. Users or groups of users do not need to be mapped here if they are going to be derived in real time. Perform this step only for users or groups that are constants, known in advance. For example, you do not have to map collectors, who are derived in real time.
In Oracle Workflow, load the following workflow roles:
Oracle Workflow Administrator. This role defines all workflow users and responsibilities and provides access to Oracle Workflow administration features. See: Identifying the Workflow Administration Role in the Oracle Workflow Administrator's Guide.
System Administrator. Load the SYSADMIN role, if not already loaded.
By default, a seeded System Administrator responsibility exists for all notifications that inform a System Administrator about a system or setup problem.
If any of these notifications need go to a different user, then you can change it for each node having "Inform Sysadmin" in its title.
To do so, in Oracle Workflow, open the Node Properties and choose a different performer from the list (which would be available from users or groups you mapped in the previous step).
(Optional) Evaluate the role of the Receivables user at your enterprise. The Receivables user's approval of a credit request initiates the creation of the credit memo.
The AME rule that you define using the Receivables Credit Memo Receivables transaction type determines the Receivables user. If you want to change the Receivables user, then change the AME rule. See: Oracle Approvals Management Setup.
However, if you want different users to assume multiple Receivables user functions, then override the AME rule by updating the following roles:
Receivables Contact. Define the user to contact when Receivables fails to create a credit memo for an approved request. The Credit Memo Request process notifies the person assigned to this role to make a correction and resubmit, or to request a manual credit memo entry.
This Receivables user is used in the AME Credit Memo Creation process, in the Credit Memo Creation Problem - Inform Receivable User node.
Receivables Manual Entry. Define the user to contact when a request is made for a manual entry. This Receivables user is used in the AME Credit Memo Creation process, in the Request for Manual Entry - Inform Receivable User node.
To update the previous roles, open the properties for the node, update the performer type to Constant, assign the selected user, and apply your changes.
See: Roles.
(Optional) Assign the credit memo batch source that you created in Receivables to the Batch Source Name item attribute.
Using the Oracle Workflow Builder, load the AR Credit Memo Using AME item type. Open the Properties sheet for the Batch Source Name item attribute and, in the Default Value field, enter the name of the credit memo workflow batch source that you previously defined.
Do this only if you want all credit memos generated by this workflow to use this batch source. Otherwise, do not enter a value here.
For more information, see: Modifying Objects in Oracle Workflow Builder.
Create a view called WF_LANGUAGES that identifies the languages defined in your installation. Oracle Workflow uses this view to create a row in its translation tables that maps to a row found in its non-translated base table for each installed language.
Define the environment variable WF_RESOURCES. You only need to define this variable if you are not using the version of Oracle Workflow embedded in Oracle Applications.
Identify the Web Agent to be used by the Credit Memo Request process. This step identifies the Oracle Web Agent that Oracle Workflow uses to access its Web components.
To use Oracle Workflow web pages and the Workflow Monitor at your site, install Oracle WebServer. For more information, refer to the Oracle Workflow Administrator's Guide and your Oracle WebServer documentation.
Secure your workflow database connection descriptor (DCD) using the Oracle WebServer authentication feature. This step ensures that only authorized users can access workflow processes.
If you want users to receive notifications via email, set up the Notification Mailer program. You can modify the templates for your electronic mail notifications and customize the logo and explanatory text that appears on your Workflow Notifications Web page.
Set up background Workflow Engines to control the load and throughput of the primary Workflow Engine on your system. You can specify the cost threshold level of your primary and background engines to determine which activities an engine processes and which activities the engine defers.
Modify the default workflow timeout periods for your activities. The default timeout period is three days.
See: Activities.
The AME Credit Memo Request workflow routes a credit memo request according to the business rules that you define in AME.
To define a rule in AME, you use attributes and conditions. Receivables provides you with a selection of predefined attributes, but you can define additional attributes. See: AME Attributes for the AME Credit Memo Request Workflow.
The AME workflow consists of three phases, known as transaction types in AME. To implement the AME workflow, you must set up these three transaction types:
The following section describes the basic setup, including some example rules, that is required to implement this workflow. However, you can use AME to create as many rules as you need for each phase of this workflow.
For the first workflow phase, define an AME rule to identify the collector who must evaluate a request before the request can proceed through the approval chain.
Create an approval group with an Action List of dynamic. In the Query box, include the following SQL statement exactly as shown:
SELECT ar_ame_cm_attributes_api.get_collector_id (:transactionId) FROM DUAL
This statement locates the collector who is assigned to the customer account or bill-to site.
Both the Limits Only and HR Hierarchy Limits paths use this approval group, which you set up once. This provides the same Find Collector functionality as the original workflow without AME.
Customers who do not assign their collectors by customer account or bill-to site must create a new package to find the collector. To achieve this, modify the SELECT statement for the approval group.
Your new package should point to a function that confirms that the collector exists on the AR_COLLECTORS table. If the collector exists, then the function should return the Employee ID to the AME workflow. Without this function, the new package will fail validation.
Suggestion: The descriptive flexfield on the AR_COLLECTORS table can store other attributes that your new function can call, such as cost center or region.
Create a rule for collector assignment. For example, this table illustrates the settings for one rule that uses the approval group created in the previous step:
| Rule Setting | Value |
|---|---|
| Rule type | pre-list approval-group rule |
| Approval type | group approvals before the chain of authority |
| Approval | require pre-approval from <Collector approval group that you previously defined> |
| Ordinary-Condition Attributes | ALWAYS_TRUE |
| Ordinary Conditions | ALWAYS_TRUE is TRUE |
For the next workflow phase, define AME rules to identify the approvers in this credit memo request's approval chain.
After the collector approves a request, the workflow uses these rules to find the next approver in the approval chain.
An approval chain can follow either the Limits Only path, or the HR Hierarchy Limits path. Define a set of rules for each path that you intend to use.
Attention: In AME, confirm that all existing rules apply to your business needs. If extraneous rules exist, then the transaction approval process might fail.
Complete the following steps for the Limits Only path:
Create approval groups, and assign members.
Then, add approvers to each group. When adding more than one approver to a group, assign a sequence to each approver.
For example:
Create one approval group that includes John Smith, who can approve all requests less than or equal to $1,000.
For all requests greater than $1,000, create another approval group that includes John Smith and Jane Doe. In this group, John is the first approver, and Jane is the second approver.
Create conditions. Use the seeded conditions if they meet your business needs; otherwise, create your own conditions.
Create ordinary conditions for limits for the TRANSACTION_AMOUNT attribute.
Using the example from the previous step, you might create one condition for all transactions with amounts between $0 and $1,000, and one condition for all transactions with amounts between $1,001 and $100,000.
Attention: When creating the condition with the highest upper limit, use an upper limit that is greater than what you will ever need. Otherwise, if the credit memo request is for $200,000 but you set an upper limit of $100,000, then AME will incorrectly assume that the $200,000 request satisfies all conditions.
Create Limits Only rules that include the conditions you just defined.
The following table illustrates the settings for one rule that you might create. To cover all the conditions that your enterprise requires, you will need to create multiple rules.
| Rule Setting | Value |
|---|---|
| Rule type | pre-list approval-group rule |
| Approval type | group approvals before the chain of authority |
| Approval | require pre-approval from <Limits Only approval group that you previously defined> |
| Ordinary-Condition Attributes | APPROVAL_PATH, AR_REASON_CODE, TRANSACTION_AMOUNT |
| Ordinary Conditions | APPROVAL_PATH in {LIMITS}, AR_REASON_CODE in {DAMAGED PRODUCT}, $1,001 < TRANSACTION_AMOUNT <= $100,000 USD |
Note: When evaluating transactions for approval, AME automatically converts foreign currency transaction amounts into your functional currency, unless you specify a currency in your rules.
Complete the following steps for the HR Hierarchy Limits path:
Create conditions. Use the seeded conditions if they meet your business needs; otherwise, create your own conditions.
Create HR Hierarchy Limits rules that include the conditions you just defined.
Attention: Receivables seeds an example rule, HR Hierarchy Limits. Delete this rule if you do not use it.
Your rules also include approval types. For example, you can define rules that look at:
Supervisory or job levels
Supervisory levels refer to the number of supervisors to ascend in a hierarchy. Job levels refer to the job level to ascend to in a hierarchy. See: Oracle Approvals Management Implementation Guide.
Both supervisory or job levels, and approval limits
To create the latter type of rule, you might create job levels in HRMS and assign them to your approvers. You can then define rules in AME that use both job levels as well as transaction amount limits.
For example, this table illustrates the settings for one such rule:
| Rule Setting | Value |
|---|---|
| Rule type | list-creation rule |
| Approval type | chains of authority based on absolute job level |
| Approval | Require approvals up to at least level 2 |
| Ordinary-Condition Attributes | APPROVAL_PATH, AR_REASON_CODE, TRANSACTION_AMOUNT |
| Ordinary Conditions | APPROVAL_PATH in {HR}, AR_REASON_CODE in {DAMAGED PRODUCT}, 0 < TRANSACTION_AMOUNT <= $200 USD |
The rule illustrated in the previous table states that for requests between $0 and $200, approval is required by an employee who has a job level of at least level 2.
Complete the following optional steps for both paths:
(Optional) Set the ALLOW_REQUESTER_APPROVAL attribute to False.
Set this attribute to False only if you do not want requestors to approve their own credit memo requests.
(Optional) Create ordinary conditions for the AR_REASON_CODE attribute, using the lookup codes that you defined for the CREDIT_MEMO_REASON lookup type. See: Oracle Receivables Setup.
Note: Enter the lookup codes exactly as you defined them in the Code field.
Complete this step only if you plan to use reason codes as part of your AME rules.
For the final workflow phase, define an AME rule to identify the Receivables user whose approval initiates the creation of the credit memo.
Create an approval group for the Receivables user, and assign a single member.
Both the Limits Only and HR Hierarchy Limits paths use this group. This group, which you set up once, must include only one member.
Create a rule for the Receivables user.
For example, if you want the Receivables user to be the final approver before credit memo creation, then use the setup that the following table illustrates:
| Rule Setting | Value |
|---|---|
| Rule type | post-list approval-group rule |
| Approval type | group approvals after the chain of authority |
| Approval | require post-approval from <approval group that you previously defined> |
| Ordinary-Condition Attributes | ALWAYS_TRUE |
| Ordinary Conditions | ALWAYS_TRUE is TRUE |
Other Sources
Conditions, Oracle Approvals Management Implementation Guide
Rules, Oracle Approvals Management Implementation Guide