有谁做过AME，R12版的

vvyjp

To implement AME, you need to carry out the following steps:
1. Install the application.
AME's installation routines and administration features determine which
applications can use AME. Installation and administration are typically jobs for a
technical specialist. Installation is generally done only once, and administrative
tasks (using AME's Administrator Dashboard) are usually only necessary to enable
a new application to use AME, or to access or clear a transaction's error log.
2. Set up AME security by completing the following:
• Attach the predefined roles to a user or group of users.
AME uses the Role Based Access Model (RBAC) to provide users access to
AME functions. This access model has the following predefined roles:
• Approvals Management Administrator
• Approvals Management Analyst
• Approvals Management System Viewer
• Approvals Management System Administrator
• Approvals Management Process Owner
Each of the five predefined roles has a specific set of functional grants. The
grants provide users access to AME. To enable functional grants, you must
assign roles to users using the User Management page. For information about
accessing User Management page, see: Oracle Applications System
Administrator's Guide - Security.
Set up user access as follows:
1. Login as Administrator.
2. Select the User Management responsibility.
3. Select the Users page.
4. Search for the user to whom you wish to grant AME roles.
5. In the results table, click Update. In the Update User page, you can view
user details along with a list of roles available to the user.
6. Click Assign Roles.
7. Select the roles from the resulting list and click Apply.
When you assign any of the five predefined roles to a user, you are indirectly
assigning AME responsibilities to the user.
Note: You can create custom roles to meet your requirements.
See: Oracle Applications System Administrator's Guide -
Security. For information about permission sets for roles, see:
AME Roles and Responsibilities, page 2-14.

• Grant data access to users.
As AME restricts access to transaction types using Data Security, you grant
users access to the transaction types using the Grants page. Set up user access as
follows:
1. Login as Administrator.
2. Select the Functional Administrator responsibility.
3. Select the Grants tab.
4. Click Create Grant.
5. Select Specific User as grantee type.
6. Select the user as grantee key.
7. Select AME Transaction Types as object:
1. All rows: This grants access to all AME Transaction Types to the User
2. Instance: This grants access to a specific AME Transaction Type
specified by the following parameters: FND_APPLICATION_ID =>
Application ID of the application to which the transaction type belongs
TRANSACTION_TYPE_ID => Unique identifier of the AME
Transaction type within application
3. Instance set: This grants access to one or more AME Transaction Types
specified by the following parameters:
• Use the predefined instance set AME Transaction Type Instance
Set.
• In the next page, select FND_APPLICATION_ID as Parameter1 and
a wild card search string for TRANSACTION_TYPE_ID as
Parameter2.
8. In the next page there will be three options for instance type: select AME
Calling Applications as the permission set.
9. Review and Finish.
For more information, see: Oracle Applications System Administrator's Guide -
Security.
Note: If you are an existing customer, then you must ensure your
existing users have the Approvals Management Business Analyst
and Approvals Management Administrator responsibilities. You
must run the Approvals Management Post Upgrade Process to
migrate existing users to the new responsibilities. See: Running the
Approvals Management Post Upgrade Process

vvyjp

3. Set the user profile - AME:Installed
This user profile is predefined by AME and is available for integrating applications
such as Internet Expenses, iProcurement, to make use of. It is set at the application
level and can be used by that application to determine if AME is installed and if so
what action to take. In some instances this determination is used to decide if AME
should be used for the approval process of that application, this is not always the
case however. Please review the specific documentation of the integrating
application to determine if that application uses this user profile.

vvyjp

4. Configure transaction types.
An application administrator should review AME's configuration-variable values as
soon as AME is installed and its security has been set up. AME has the following
kinds of configuration variables:
• Single-Valued Configuration Variables
AME's configuration variable distributedEnvironment has a single value for the
entire application. This variable describe various aspects of AME's computing
environment. You must set its value for AME to function properly.
• Transaction-Type-Specific Variables
Other AME configuration variables can have a default value, as well as a value
for each transaction type. These variables are:
• adminApprover
• allowAllApproverTypes
• allowAllItemClassRules
• allowFyiNotifications
• currencyConversionWindow

• forwardingBehaviors
• productionFunctionality
• purgeFrequency
• repeatedApprovers
• rulePriorityModes
These variables determine many aspects of how AME generates a transaction
type's approval processes and are similar to the mandatory attributes. The
difference is, their values are always constant for all transactions in the
transaction type. Ensure you are satisfied with these variables' default values
before using AME.
Note: You must run the purge utility from the concurrent manager
daily to remove old transaction data. Failure to perform this task will
eventually result in performance degradation and unlimited growth of
the size of certain AME database tables. See: Purging Transaction Data

vvyjp

Implementing the Transaction Type
To implement the transaction type, you need to specify or create, if required, the
following components of the approval process:
1. Create item-class use (Optional).
Once you have documented the approval processes you want a transaction type to
implement, you can begin implementing the transaction type. The first step is to
register any custom item-class use your transaction type requires.
2. Create transaction attributes (Optional).
In AME, an attribute is a named business variable such as
TRANSACTION_AMOUNT, whose value AME fetches at run time, when it
constructs transactions' approver lists. Only a user with the Application
Administrator responsibility can create or alter attributes (using the Attributes tab),
because doing so generally requires entering or changing an SQL query.
AME includes the attributes commonly required for the transaction type(s) of each
application that can use AME. If your organization has customized an application,
or has defined flexfields in it, and wants to use these in the application's approval
processes, a user with the AME Application Administrator responsibility must
create new attribute names representing the customizations or flexfields, and must
define SQL queries that fetch their values at run time. Business users can only select
from existing attributes, when they create conditions for AME rules.
3. Create conditions (Optional).
In AME, a condition specifies a list or range of attribute values required to make a
rule apply to a transaction. For example:
Example
USD1000 < TRANSACTION_AMOUNT < USD5000
You create and maintain conditions using the Conditions tab.
4. Create approver groups (Optional).
You can create AME rules to include one or more approver groups in a transaction's
approver list. You create and maintain approver groups using the Approver
Groups tab. You must create an approver group before using it in an
approval-group rule. You can also add existing approver groups to an
approval-group rule.
5. Prepare to use the action types.
You add action types to a transaction type using the Action Types tab. The action
types available to use are:
• Predefined action and approver types
AME comes with many predefined action types and actions for them. The
predefined action types currently support three types of approvers: HR
employees (in the HR supervisory hierarchy), HR positions (in the HR position
hierarchy), and Oracle Applications (FND) users. The predefined action types
ascend the HR hierarchies in many different ways.
An action determines which approvers are included in a transaction's approver
list. Typically an action type represents a way to ascend a certain organizational
hierarchy, including in a transaction's approver list an appropriate chain of
authority from the hierarchy; and an approval specifies where the chain starts
and ends. If your organization wishes to require approvals from an
organizational hierarchy that none of AME's predefined action types ascend,
you need to use a custom action type. The procedure to create a custom action
type is detailed within the AME Developers guide.
• Custom action and approver types
AME can support approvers from any originating system registered with
Workflow Directory Services (that is, any entity that can function in Workflow
as an approver). If your organization requires chains of authority structured
differently than those generated by AME's predefined action types, or
approvals from approvers in an originating system that AME does not yet
support, you may elect to code a custom action type. This requires a significant
programming effort (a typical action-type handler PL/SQL package is several
hundred lines of code), and an application administrator must register the
resulting PL/SQL package with AME. You may also have to register the
non-predefined approver type with AME. Currently there is no user interface to
register an approver type; one must do so from the SQL*Plus command line.
We encourage you to request that AME development release a patch
supporting the approver type your organization requires, rather than
registering the approver type yourself.
• Add approvals to existing approval types
Your organization may plan to use AME's predefined action types, but may
require additional actions. For example, the supervisory-level action type comes
with actions for a supervisory hierarchy having at most 10 levels. If your
organization has 15 levels, you must create supervisory-level actions for levels
11-15. An application administrator can add these action types using the actions
tab.
• Preparing to use the Job-Level approval types
If your organization plans to use one of the job-level action types, it must first
assign a job level to each job defined in HRMS (that is, it must first populate the
approval_authority column of the HRMS table per_jobs). Your organization
should also have a business process for maintaining job levels.
6. Define approval rules.
With your item-class use, attributes, conditions, approver groups, action types, and
actions prepared, you can create your approval rules using the Rules tab. Again, an
approvals matrix or decision tree may serve as a convenient checklist.
In AME, an approval rule associates one or more conditions with an approval
action. The rule applies to a transaction if and only if all of the rule's conditions are
true for the transaction.
Each application that can use AME defines one or more transaction types. Each
transaction type has its own set of approval rules. Several transaction types can
share attribute names, while defining separate use for those attribute names. This
makes it possible for several transaction types to share conditions and rules. See:
Using Attributes, page 3-7.
7. Test approval rules.
Once a transaction type has a set of rules, it is critical to test the rules, to ensure they
apply to the proper cases and do not contain logical gaps or inconsistencies. You
can store these test cases to reuse later.
There are three ways to test a transaction type:
• Create a transaction in the integrating application, and use the application's
user interface to view the transaction's approver list.
• Create a transaction in the integrating application, and use AME's Test
Workbench tab to view the transaction's approver list.
• Create a test transaction and view its approver list using AME's Test
Workbench tab.
8. Create custom transaction types.
It is possible to create a custom transaction type from scratch, for instance to use
AME as the approvals engine for a custom application. Transaction-type creation is
beyond the scope of this guide. If your organization wants to create a custom
transaction type, contact Oracle Support and request the Oracle Approvals
Management Developer Guide. Also see: Creating a Transaction Type, page 9-11.
9. Configure Oracle applications to use AME.
An Oracle Application should be configured to use AME only after thoroughly
testing the set(s) of rules defined for that application's transaction type(s) in AME.
Consult the application's user or technical documentation to learn how to configure
the application to use AME.

vvyjp

Purging Transaction Data
You can run the purge utility to remove o
You can run the purge utility to remove old transaction data. You can define the age of
transaction data by setting the required value for the configuration variable
purgeFrequency. See: Configuration Variables, page 9-3
To purge transaction data:
Use the Submit Request window.
1. Using the System Administrator responsibility, navigate to the Submit Request
window.
2. Enter Approvals Management Transaction Data Purge as the name of your request.
3. Click in the Parameters field if the Parameters window does not open. If the
Parameters window opens by default, then enter the parameter details specified in
the next steps.
4. Select the transaction type whose old data you want to purge.
5. Select the transaction to be purged. You can purge all completed, in progress,
approved, and rejected transactions.
6. Click OK.
7. Click Submit to purge the old transaction data.
Running the Approvals Management Post Upgrade Process
If you are an existing customer, then you must ensure your existing users have the
Approvals Management Business Analyst and Approvals Management Administrator
responsibilities. You must run the Approvals Management Post Upgrade Process to
migrate the existing users to these responsibilities.
Use the Submit Request window.
To run the Approvals Management Post Upgrade Process:
1. Using the System Administrator responsibility, navigate to the Submit Request
window.
2. Enter Approvals Management Post Upgrade Process as the name of your request.
3. Click in the Parameters field if the Parameters window does not open. If the
Parameters window opens by default, then enter the parameter details specified in
the next steps.
4. To migrate, do one of the following:
• Select MIGRATE_USERS to migrate the existing users.
• Select MIGRATE_ITEM_CLASS_USAGES to migrate the item class use.
• Select MIGRATE_ALL to migrate users and item class use.
5. Click OK.
6. Click Submit to migrate existing users to the Approvals Management Business
Analyst and Approvals Management Administrator responsibilities.

vvyjp

终于测通了

linchengfang

真是个神人啊,你好像哪一块都熟啊!
正发愁呢
客户现在有这种需求, 订单(先不管行还是头)折扣在一定区间需要不同的人来审批,看USER GUIDE是可以实现.对吗?

linchengfang

不好意思, 是销售报价单!

reaganhuang

关注