This topic explains what each configuration variable means, and whether a configuration variable can have a transaction-type-specific value. Additionally, it indicates in each case whether a transaction type can override the default value.
The adminApprover variable identifies the person or user account that AME identifies as a transaction's next required approver to the application requesting the approver's identity, when AME encounters an exception while generating the transaction's approver list. A transaction type can override this variable's default value.
A widget is provided to select the person or the user who is the adminApprover.
The allowAllApproverTypes configuration variable is boolean value. When its value is 'yes' for a given transaction type, the transaction type can use rules that use all approver types known to AME. When the variable's value is 'no', the transaction type can only use rules that use the HR person (employee) and FND (Oracle Applications) user approver types.
When you select the allowAllApproverTypes variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents a 'yes' and 'no list . Select one of these values, and then select the 'Submit Changes' button to update the variable's default value.
Note: You cannot edit this variable's value for a specific transaction type; you can only edit the default value.
The allowAllItemClassRules configuration variable is boolean valued. When its value is 'yes' for a given transaction type, the transaction type can use rules pertaining to any item class. When the value is 'no', the transaction type can only use header-level rules.
When you select the allowAllItemClassRules variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents a select list with the possible values 'yes' and 'no'. Select one of these values, and then select the 'Submit Changes' button to update the variable's default value.
Note: You cannot edit this variable's value for a specific transaction type; you can only edit the default value.
The allowFyiNotifications variable is boolean valued. When its value is 'yes' for a given transaction type, the transaction type can have a rule use that generate FYI notifications. When its value is 'no', the transaction type can only have a rule use that generate requests for approval.
When you select the allowFyiNotifications variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents a select list with the possible values 'yes' and 'no'. Select one of these values, and then select the 'Submit Changes' button to update the variable's default value.
Note: You cannot edit this variable's value for a specific transaction type; you can only edit the default value.
The currencyConversionWindow variable identifies how many days AME should look back , at most, to find the a currency conversion rate. The default value is set to 120 days. AME uses the GL Daily Rates table and associated routines to perform currency conversions.
When you select the currencyConversionWindow variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents a form that lets you enter the variable's value. Enter the value, and then select the 'Submit Changes' button to update the variable's default value.
The distributedEnvironment variable indicates whether AME has been installed in a distributed-database environment. It has two possible values: 'yes' and 'no'. A transaction type cannot override this variable's default value.
AME has its own exception log, and in most cases it logs runtime transactions to that log. If the application that owns a given transaction type calls AME from within a workflow, AME also logs exceptions to Workflow (see Runtime Exceptions: page 116 for details); and it uses an autonomous transaction to commit exception data to its own log, to avoid interfering with Workflow's transaction management.
If however AME is installed in a distributed-database environment, and is called from within a workflow, it cannot initiate an autonomous transaction, because such transactions are not yet possible in a distributed environment. In this case it must query Workflow directly (where possible) for a record of AME exceptions. This log is less robust than AME's own log, and so AME avoids using it where possible.
In short, the distributedEnvironment variable is necessary to make sure AME logs exceptions internally whenever possible, while avoiding autonomous transactions where they would produce runtime errors.
The forwardingBehaviors screen defines a set of constants, which determines how AME handles forwarding in a number of special cases.
The behavior for forwarding to someone not already in the list is always the same: the forwardee is inserted as an approver of the same type, immediately after the forwarder. When the forwarder and forwardee are chain of authority approvers, and the forwarder lacks final authority, AME extends the chain of authority starting from the forwarder until it finds someone with final authority. (This would normally be the typical case.).
AME predefines default values that are expected to be the normal use for each forward type. Oracle Application teams seeding transaction types can override these defaults to ones more suitable for the particular business process.
There are a number of different types of forwarding scenario that might occur during the approval process. For each of the listed scenario below, the AME engine can be instructed to amend the approver list in a pre-defined way. Not all possible outcomes are applicable for each forwarding scenario, these all indicated below.
A chain of authority approver forwards to a previous approver in the same chain of authority.
A chain of authority approver approves and forwards to a previous approver in the same chain of authority.
A chain of authority approver forwards to a subordinate in the same approver hierarchy, but not in the same chain of authority.
A chain of authority approver approves and forwards to a subordinate in the same approver hierarchy, but not in the same chain of authority.
A chain of authority approver forwards to another approver already in the approver list, but not in the same hierarchy.
A chain of authority approver approves and forwards to another approver already in the approver list, but not in the same hierarchy.
An ad-hoc approver forwards to an approver already in the approver list.
An ad-hoc approver approves and forwards to an approver already in the approver list.
Depending on the case, the allowed sub-values may include any of the following:
ignore: Ignore the forwarding (treat it as an approval).
forwardee only: Just add the forwardee to the approver list.
forwardee then forwarder: Add the forwardee and the forwarder to the approver list.
skip forwarder: Extend the chain of authority starting with the forwardee, but skip the forwarder in the extended chain.
repeat fowarder: Extend the chain of authority starting with the forwardee, and include the forwarder in the extended chain.
remand: Add to the approver list all approvers between the forwardee and the forwarder including the forwarder.
When you select the forwardingBehaviors variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents eight select lists, one for each special case. Select a sub-value on each select list, and then select the 'Submit Changes' button to update the variable's default sub-values.
The productionFunctionality variable indicates which kinds of productions are allowed within a given transaction type. The possible values are as follows:
All production rules
Per-approver production rules
No production rules
Per-item production rules
When you select the productionFunctionality variable at step 4 above, the 'Edit a Configuration Variable Default Value' form presents a radio-button input with these options. Select the one you want, and then select the 'Submit Changes' button to save the value. (Note that when you cannot edit this variable's value for a specific transaction type; you can only edit the default value.)
The purgeFrequency variable indicates how many days AME should preserve temporary data before purging it from AME's database tables. The value must be a positive integer.
When a transaction's temporary data is purged, its approval process starts over, as if no approver had approved the transaction. Therefore, the purgeFrequency variable's value should be high enough so that no transaction will require this many days to be approved by all of its approvers. At the same time, the purge frequency should be sufficiently low to avoid unnecessary growth in the size of AME's temporary-data tables.
A transaction type can override this variable's default value. When a transaction type overrides purgeFrequency, AME preserves that transaction type's temporary data only for the overriding value. This enables you to set the purge frequency differently for each transaction type, adjusting its value for each to a reasonable upper limit on the number of days required for a transaction of that type to complete its approval process.
Indicates how many times to require an approver's approval in the absence of forwarding. An approver may appear many times within the overall approval list. This can be due to a number of factors such as the approver exists as a pre/post approver as well as appearing within a chain of authority. In these circumstances it may be desirable to restrict so that the approver is only required to approve once in the following circumstances.
One of the following options should be selected:
Once per transaction
Once per item class
Once per item
Once per sublist
Once per action type
Once per group or chain
Each occurrence
Thus, you can choose to make an approver occur at most once within any given subtree of the approver-list tree.
Note: AME considers an approver as repeated only if the approver exists in the approver list with matching approval category. If the approver exists in the approver list twice with approval category as 'FYI' and 'Approval', then the approver will not be marked as repeated.
The rulePriorityModes variable has a set of sub-values for each rule type. A rule type's rulePriorityModes values determine whether AME allows rule use priorities for the rule type, within a given transaction type. The values also determine how AME handles priorities, when they are enabled.
There are two sub-values for each rule type. The priority mode indicates whether priorities are allowed, and if so, how AME interprets them. The modes that enable priorities use a numerical threshold. If the mode is disabled, AME does not allow the transaction type to use rule use priorities for the rule type. If the mode is absolute, rules whose conditions are satisfied, and which have rule use priorities that do not exceed the threshold, apply.
The relative priority mode is very useful, but it takes more explaining. In general, suppose the threshold is t, and a given transaction satisfies k rules' conditions. Let P be the set containing the t numerically lowest distinct priorities among the priorities of the satisfied rules' use. Then all satisfied rules whose use are in P apply to the transaction.
For example, suppose the threshold is three, and a transaction satisfies the conditions of five rules. Suppose also that these rules' use have priorities one, two, two, three, and four. Then the top three priorities are one, two, and three, so all but the last rule apply to the transaction.
The recordDeviations configuration variable enables you to record deviations. You must set this configuration variable to YES at transaction type level to track the deviations.