December 16th, 2010 Matt
Back in September, I wrote a post which had some SQL to provide a list of Workflow timeout values which can be used in profile option values.
The code sample below was something that Gary Derrick put together which does a similar task, albeit more simplified than the version I produced in the original post:
SQL="SELECT a.meaning,
a.v
INTO :visible_option_value,
:profile_option_value
FROM
(SELECT DECODE(LEVEL - 1,0,'No Timeout'
, DECODE(LEAST(LEVEL - 1,59),LEVEL - 1,TO_CHAR(LEVEL - 1)
||' Minute'
||DECODE(LEVEL - 1,1,'','s')
, DECODE(LEAST(LEVEL - 1,1439),LEVEL - 1,TO_CHAR((LEVEL - 1)/60)
||' Hour'
||DECODE(LEVEL-1,60,'','s')
, TO_CHAR((LEVEL-1)/1440)
||' Day'
||DECODE(LEVEL - 1,1440,'','s')))) meaning
, LEVEL - 1 v
FROM dual
CONNECT BY LEVEL <= 7200
) a
WHERE a.v IN (0, 1,2, 60, 120, 1440, 2880)"
COLUMN="Meaning(15)"
HEADING="Timeout(15)"
The code generates a list of values based on the number of minutes you specify in the WHERE clause. In this example, the list of values would be no timeout (0), 1 Minute(1), 2 Minutes (2), 1 Hour (60), 2 Hours (120), 1 Day (1440), 2 Days (2880) – if you want different values, then change the number of minutes to include in the query.
The value of the profile option can then be retrieved directly by the Workflow process without any need to manipulate it – it’s ready to use in the code, but is also human-friendly in terms of what the LOV displays.
Hope you find it useful – thanks Gary!
Posted in Functional, Oracle, Technical | No Comments »
October 4th, 2010 Matt
Another code snippet from my archive.
On a number of projects, we have implemented approvals for service requests based on the HR supervisor hierarchy, and occasionally during testing the approval notification ends up in an unexpected place. If you are using AME, then you can run the live test based on the service request ID to find out who AME expects to notify, but if you are using an SR workflow then this becomes a little more complex.
The code sample below takes the SR number as the start point, and from the primary contact walks up the HR supervisor hierarchy until there are no more supervisors found.
Enjoy!
SET SERVEROUTPUT ON SIZE 1000000
DEFINE sr_number = &1
DECLARE
--
CURSOR c_per_info ( cp_party_id IN NUMBER ) IS
SELECT full_name
FROM apps.per_people_x
WHERE person_id = cp_party_id;
--
CURSOR c_get_manager ( cp_party_id IN NUMBER ) IS
SELECT paaf.supervisor_id
FROM apps.per_all_assignments_f paaf
JOIN apps.per_assignment_status_types past ON
( paaf.assignment_status_type_id = past.assignment_status_type_id )
WHERE paaf.person_id = cp_party_id
AND paaf.effective_start_date <= SYSDATE
AND NVL(paaf.effective_end_date, SYSDATE) >= SYSDATE
AND paaf.primary_flag = 'Y';
--
CURSOR c_party_from_sr_number ( cp_sr_number IN NUMBER ) IS
SELECT party_id
FROM apps.cs_hz_sr_contact_points
WHERE incident_id = ( SELECT incident_id
FROM apps.cs_incidents_all_b
WHERE incident_number = cp_sr_number )
AND primary_flag = 'Y';
--
v_start PLS_INTEGER;
v_curr_person per_people_x.full_name%TYPE;
v_next_person per_people_x.full_name%TYPE;
v_check BOOLEAN;
--
BEGIN
--
v_check := TRUE;
--
OPEN c_party_from_sr_number ( cp_sr_number => &sr_number );
FETCH c_party_from_sr_number INTO v_start;
CLOSE c_party_from_sr_number;
--
IF v_start IS NULL THEN
DBMS_OUTPUT.PUT_LINE('No SR found for SR number &sr_number');
v_check := FALSE;
END IF;
--
IF v_check THEN
WHILE v_start IS NOT NULL LOOP
OPEN c_per_info ( cp_party_id => v_start );
FETCH c_per_info INTO v_curr_person;
CLOSE c_per_info;
--
OPEN c_get_manager ( cp_party_id => v_start );
FETCH c_get_manager INTO v_start;
CLOSE c_get_manager;
--
OPEN c_per_info ( cp_party_id => v_start );
FETCH c_per_info INTO v_next_person;
CLOSE c_per_info;
--
IF v_start IS NULL THEN
DBMS_OUTPUT.PUT_LINE ( 'Current person '
||v_curr_person
||' has no supervisor' );
ELSE
DBMS_OUTPUT.PUT_LINE('Current person '
||v_curr_person
||' is supervised by '
||v_start
||' / '||v_next_person );
END IF;
END LOOP;
END IF;
END;
/
Posted in Functional, Oracle, Technical | 1 Comment »
September 28th, 2010 Matt
I’m currently migrating my code archives from one hard drive to my new QNAP network attached storage device, and found a whole load of useful SQL scripts that have been sitting around waiting for me to do something with them. Amongst them was this one….
Many Workflow processes require a timeout which is dynamic, and the way that I typically recommend my clients to do this is to define a profile option to store the value, and then reference this in the code. Unfortunately, quite a few Oracle environments that I have seen do this but provide no validation on the profile, and no clear indication of what the value means – setting the profile to 1 might mean one second, one hour, one day…
So, here’s some quick example code of SQL validation that can be put on a profile option to validate against a list of values of timeouts in days, up to 10 days:
SQL="SELECT decode ( timeout, 0, 'No timeout', meaning ) meaning
, timeout
into :visible_option_value, :profile_option_value
FROM ( SELECT TO_CHAR(level - 1)||' days' meaning
, level - 1 timeout
FROM dual
CONNECT BY LEVEL <= 11 )"
COLUMN="Meaning(15)"
HEADING=""Timeout Days"(15)"
And here’s a longer version, which provides a list of timeouts in hours from no timeout to 10 days:
SQL="SELECT DECODE ( timeout_period, 0,'No timeout',meaning) meaning
, timeout_period
into :visible_option_value, :profile_option_value
FROM ( SELECT CASE
WHEN (level-1) < 24 THEN
CASE WHEN (level-1) = 1 THEN '1 hour'
ELSE
TO_CHAR(level-1)||' hours'
END
ELSE
CASE WHEN MOD((level-1),24) = 0 THEN
CASE WHEN level = 25 THEN '1 day'
ELSE
TO_CHAR(TRUNC((level-1)/24))||' days'
END
ELSE
CASE WHEN TRUNC((level-1)/24) = 1 THEN
CASE WHEN MOD((level-1),24) = 1
THEN '1 day and 1 hour'
ELSE
'1 day and '||MOD((level-1),24)||' hours'
END
ELSE
CASE WHEN MOD((level-1),24) = 1
THEN TO_CHAR(TRUNC((level-1)/24))
||' days and 1 hour'
ELSE
TO_CHAR(TRUNC((level-1)/24))
||' days and '
||MOD((level-1),24)||' hours'
END
END
END
END meaning
, (level-1) / 24 timeout_period
FROM dual
CONNECT BY LEVEL <= 241 )"
COLUMN="Meaning(15)"
HEADING=""Timeout Period"(15)"
Enjoy! The SQL file for the above examples can be found here.
Posted in Functional, Oracle, Technical | 1 Comment »
September 26th, 2010 Matt
I recently had to remove some email accounts from Oracle Email Center, because the environment had been cloned from one instance to another and referenced obsolete accounts. An easy task, one might think – if they have never worked with EMC before… Oracle produce some guidance on how to clear the accounts out, but I’ve never had a complete list of instructions before, so thought I’d document it here. I’m sure that there are ways to remove the accounts purely functionally, but if there is, I’ve not found it – the instructions here include a mix of functional changes and direct table updates, so as ever you use it at your own risk.
Step 1 – Ensure that there are no Agents assigned to the email account
Using the Email Center Administrator responsibility, navigate to the agents association page (path Email Center Administration > Administration > Email Accounts > Associations > Agents). Choose the “Assign Agents to Accounts” drop-down, then choose the email account that you want to remove and click the Go button. Remove the agents from the account(s) if you can.
If there are emails in the agent’s inbox, you will need to log in as that person, navigate to their in box and remove the emails that are sitting there. Even if you do this, though, you may well find that you still can’t remove the agent from the account – so we’ll do a direct table update to ensure that there aren’t any emails there!
Identify the email account ID that you are looking for by running the following SQL:
SELECT email_account_id
FROM iem_mstemail_accounts
Where email_address = '<enter mailbox address here>'
/
Then identify the agent by running:
SELECT agent_id
FROM iem_agents
WHERE email_account_id = <email_ account id from above SQL>
/
Before deleting the records, I would recommend creating a backup table at this stage, e.g.
CREATE TABLE xx_iem_agents_backup AS SELECT * FROM iem_agents;
Then force the removal of the agent from the account by running the following SQL:
DELETE FROM iem_agents
WHERE email_account_id = <email account id>
AND agent_id = <the associated agent id>;
COMMIT;
So, whether you have reached this point from functional configuration or deleting the records in the Email Center tables, you should now have no agents associated with the account that you want to delete.
Step 2 – Remove the rules from the accounts
This is the one step where you should be able to do this functionally. Navigate to the rules association page (Email Center Administration > Administration > Email Accounts > Associations > Processing Rules), and choose the account that you are deleting. Make sure that there are no rules associated with the account – if there are, then expand the entry and remove them by clicking on the bin icon.
Step 3 – Empty the folders
Check whether Email Center is looking at the folders for that account – navigate to Email Center Administration >Monitoring > Download Processor and see whether there are any emails that the system is looking at.
If there are any messages on the server, then you should delete them if they are no longer needed – to do this, I open the account in my email client and remove the messages from the inbox, Oracle Processed and Oracle Retry folders. Once they are empty, the Download Processor should show that there are no messages there.
Step 4 – Make the account inactive and delete it
Theoretically, this is the last step and should be straightforward. To do this functionally, navigate to Email Center Administration > Administration > Email Accounts > Summary and find the account that you are trying to delete. Edit the configuration and change it from Active to Inactive, then return to the summary screen. If all is well, then the bin icon will be enabled and you can now delete the account. If not, then we are back into the world of SQL updates to remove the account information…
Firstly, check whether there are emails being processed for the mailbox by running the following SQL:
SELECT email_account_id
, message_id
FROM iem_rt_proc_emails
WHERE email_account_id = ( SELECT email_account_id
FROM iem_mstemail_accounts
WHERE email_address = '<enter mailbox address here>' );
If there are no rows returned, then identify the email account ID by running the subquery above:
SELECT email_account_id
FROM iem_mstemail_accounts
WHERE email_address = '<enter mailbox address here>';
Make a note of the account ID before moving onto the next section.
If there were any records returned, then delete them from the table (again, I recommend making a backup of the data first!):
CREATE TABLE xx_iem_rt_proc_emails_backup AS SELECT * FROM iem_rt_proc_emails;
DELETE FROM iem_rt_proc_emails
WHERE email_account_id = <id you made a note of> ;
COMMIT;
Next, check for any messages that are in the pre-processing stage:
SELECT email_account_id
, message_id
FROM iem_rt_preproc_emails
WHERE email_account_id = <id you made a note of> ;
If no rows are returned do nothing, but if one or more rows are returned, then do the following:
CREATE TABLE xx_iem_rt_preproc_emails_backup AS SELECT * FROM iem_rt_preproc_emails;
DELETE FROM iem_rt_preproc_emails
WHERE email_account_id = <id you made a note of> ;
COMMIT;
That should be all that you need to do, and the accounts should now be able to be deleted. Navigate to Email Center Administration > Administration > Email Accounts > Summary and check whether the bin icon for the email account is now enabled. If it is, then delete the account from the front-end. If not, then there is one final “force” that you can do from the back end:
UPDATE iem_mstemail_accounts
SET deleted_flag = 'Y'
WHERE deleted_flag = 'N'
AND email_account_id = <id you made a note of> ;
The account is now removed from Email Center.
Posted in Functional, Oracle, Technical | No Comments »
February 22nd, 2010 Matt
One of the most recent search terms that I’ve seen for my blog here was “AME dynamic approval group example” – so in this post, I’m going to go through the steps required to create a dynamic approval group and provide an example. This example continues on from part four, since we will be replacing the static approval group with a simple dynamic one.
Using the “Approvals Management Business Analyst” responsibility, in the “Approval Process Setup” panel on the right hand side of the dashboard, choose the “iRecruitment Vacancy Approval” transaction type again:
Click on the “Approver Groups” link, and we will modify the existing group from static to dynamic. Click on the “Update” icon for the Approver Group we created earlier, and then change the usage type from Static to Dynamic. As soon as the change is made, you will be shown a warning, indicating that the static approvers will be removed from the group:
Since we are going to be redefining the group completely, this is fine, so click on the “Yes” button and you will be returned to the group definition with no static approvers shown.
As a simple example, my approver group requires approval from two people – the user MATT and the HR person Tim Cleary. The SQL code required to retrieve the two records in the same query is
SELECT 'user_id:'||user_id
FROM fnd_user
WHERE user_name = 'MATT'
UNION ALL
SELECT 'person_id:'||person_id
FROM per_all_people_f papf
WHERE papf.full_name = 'Cleary, Mr. Timothy'
In the SQL above, we need to tell AME exactly what kind of approver we are retrieving – by prefixing the user record with “user_id:” and prefixing the person record with “person_id:”, AME then knows where the records are being retrieved from. Enter the SQL into the Query box, and then hit the Apply button. You can also use the Validate button, which checks that the query is structurally sound, but does not seem to check much more than that (for example, if you prefix the user record with “usssssser_id:”, it is still classed as a valid query).
That’s all there is to it – if we now go and create a new vacancy (using the same BJOSPEH user that we did in the last post), when we review the vacancy, we see that AME has added the two approvers to the bottom of the approval list:
Posted in Functional, Oracle | 1 Comment »
February 17th, 2010 Matt
In the last blog post, I detailed the functional configuration required to setup a new user with AME administration privileges. Now that the user is ready, in this post I will be going through a quick example of how AME can be used within iRecruitment.
In this example, we will implement the following approval rules for creating a new job vacancy within iRecruitment:
- When a vacancy is created, the vacancy must be approved by the supervisor of the person creating the vacancy.
- Once the supervisor has approved the vacancy, it must then be sent to a different user for final approval.
In my example, I have picked two random users within Vision – BJOSEPH (Joseph, Brian) and his supervisor, RJAMES (James, Robert).
The first rule (that the vacancy must be approved by the supervisor) is standard behaviour within iRecruitment, so there is nothing that we need to do with that. So – what do we need to do to meet the second requirement?
Firstly, we’ll create a new static AME Approval Group and add the Recruiting Administrator to that group. An Approval Group can return either a static or a dynamic list of users. Once we have created the Approval Group, we will then add the Group to the AME Rule that is used by the standard Vacancy Creation process.
Before we start, run through the standard Vacancy Creation process and see who the notification is sent to. Log in as the first user to create the vacancy – in my example, I will use the BJOSEPH user. Using the “iRecruitment Recruiter – VC” responsibility, navigate to the iRecruitment Home page, and click on the “New Vacancy” link in the sidebar:
In the “New Vacancy” window, enter a name for the vacancy and then click on the “Review” button. At this stage, we could enter more information about the vacancy, but since this is just a quick test to see the default functionality, there is nothing additional required here. The bottom of the vacancy summary shows the default approver that has been found – the supervisor of the person creating the vacancy:
As I said above – the default functionality meets our first requirement, so all we need to do is to add the additional requirements. Firstly, we need to find out what AME Transaction Type is used by the Vacancy Creation process. To do this, we need to examine the function for “Irc Vacancy Details – Create”, as shown in the screenshot below:
Navigate to the “Form” tab and open the Parameters to see the parameters which are passed to the form:
The parameter that we are interested in is “pAMETranType=IRCVACAPPROVAL”. Now that we know the name of the internal name for the transaction type (or Transaction Type Key), switch responsibility to “Approvals Management Administrator” – I will switch user completely to the AMEADMIN user we created in the last post. Navigate to the Admin Dashboard and query the IRCVACAPPROVAL Transaction Type Key:
Now that we know the name of the Transaction Type (iRecruitment Vacancy Approval), switch responsibility to “Approvals Management Business Analyst” and enter the Transaction Type in the right hand side in Step 1 of the “Approvals Setup Process”:
If you click on the “Rules” link, you can view the existing approval rules in place. Click on the link and then locate the “iRecruitment Create Vacancy” rule in the list of rules. When you open the rule, you are presented with the default rule:
Return to the dashboard, and we’ll create our custom Approval Group to add to the Rule. Under “Step 2” of the Process Setup, there is a link to “Approver Groups”. Click on the link to navigate to setup a new Approver Group, and then click on the “Create” button. The screenshot below shows the values that I have entered for my Approver Group:
The “Approver Type” can be an Applications User (FND User), a group of people (Nested Group) or an HR person (HR People). Multiple users can be added to the approval hierarchy here – I have only added one person, a user called MATT who will act as the final approver for vacancies. Click on the “Apply” button and then return to the dashboard to add this new Approval Group to the rule.
As before, click on the “Rules” link on the right hand side of the screen and locate the rule for iRecruitment Create Vacancy. Click on the update icon to open the rule details. At the bottom of the page, you will see the default action type, which seeks approval from the supervisor of the person creating the vacancy. Click on the Add Action button to add our Approval Group to the rule, as shown below:
If the “approval-group chain of authority” option is not available, this is because it has not been enabled. Click on the “Setup” tab and choose the “Action Types” submenu. You will be presented with a list of suitable action types – typically only the default “Supervisory level” one will be enabled. Click on the “Use Existing Action Type” button and navigate through the list of available types until you see the “approval-group chain of authority” type. Tick the box next to the action type and then click on the Continue button, then click on the Finish button. Now return to the rule and add the Approval Group as above.
Once you have added the action type, click on the Apply button. That’s all there is to it – now let’s check it again by logging out and creating a new vacancy. The final screenshot below shows that the new vacancy will be sent to MATT for approval as well as the originators supervisor:
Posted in Functional, Oracle | 3 Comments »
February 12th, 2010 Matt
By default, the “Approvals Management Administrator” and “Approvals Management Business Analyst” responsibilities do not have any functions associated with them, because their access is restricted by Role Based Access Control (RBAC). In this section, I will detail the steps needed to add functions so that we can get into using AME.
Firstly, we’ll create a new user for this demonstration, and assign them the two responsibilities, thus:
If I now log into the eBusiness Suite as that user and try to switch to either of those responsibilities, the system indicates that there are no functions available for the user (see screenshot below). As I said above, this is because role based access control ensures that only users with the right roles as well as responsibilities can access the functions.
So, now we need to modify the user to give them the right roles to administer AME properly. As a system administrator, open the “User Management” responsibility, as shown below.
If you do not have any functions assigned to the responsibility, then you will need to use the SYSADMIN user and assign the “Security Administrator” role to your user. Select the “Users” option to continue.
Search for the user that you want to add the functions to (in my case, the AMEADMIN user I created earlier), open the user details and then click on the “Assign Roles” button. You are then presented with a search window, where you should search for all Roles beginning “Approval”:
You are then returned to the user screen, where you should complete a justification for granting the roles to the user – if you don’t then the screen will prevent you from continuing. Once you have entered the justification, you should then hit the Apply button.
Log out as this user, and when you log in as the AME user, you now have functions associated with the two responsibilities:
Now that we have granted the roles to the user, they can access the functions correctly. However, RBAC means that when we open the Dashboard, the data is still protected and cannot be viewed:
Again, we need to grant some RBAC roles to allow the user to access the different transaction types. The main principle behind this is to enable organizations to split the Transaction Type maintenance between different roles – for example to allow HR Super Users to maintain only the HR rules.
Using a different user, navigate to the Functional Administrator responsibility and click on the “Create Grant” button to create the new grant. In this example, we will create a specific grant for the AMEADMIN user, however in the real world it is more likely that you will create the grant for a group of users. The Object is set to “AME Transaction Types”, thus:
In the second step, accept the default data context type of “All Rows” and continue to the third step. Define the “Set” to be “AME Calling Applications” as shown in the following screenshot:
Finally, review the settings that you have entered and click on the “Finish” button. In order to ensure that the changes are replicated, now flush the cache by clicking on the “Core Services” tab then choose the “Caching Framework” sub-menu. Choose “Global Configuration” from the sidebar and then click on the “Clear All Cache” button. You will be presented with a warning message (see below) which you can ignore and click on the “Yes” button.
Log out of this user and log back in as the AMEADMIN user, and navigate to one of the AME responsibilities – you are now given a list of the AME Transaction Types that are configured in the system:
In the next blog post, I’ll be providing a practical example of customizing AME within iRecruitment.
Posted in Functional, Oracle | 3 Comments »
February 8th, 2010 Matt
In the last blog post, I provided a quick overview of what AME is and what some of the benefits of using AME are. In the second post in my series on AME, I’ll be looking at the different components of AME and how they interact.
Before you start using AME, it is important that you understand exactly what the different parts of the Engine are, what you need to configure, and how they all work together. There is frequently a requirement to modify the seeded components or to create new ones for an organization, in order to develop their business rules.
Transaction Types
A Transaction Type defined the type of transaction for which the business rules and approval routes will be based. This is an eBusiness Suite transaction, for example creating a new vacancy in iRecruitment or creating purchase orders. There are many different Transaction Types seeded within the application to meet the requirements of the most common transactions which occur within the eBusiness Suite that would require an approval to take place. If you are integrating a bespoke application with AME, then new Transaction Types can be defined within AME. However, the creation of new Transaction Types is not a straightforward task, and Oracle discourage this because of the amount of programming effort that is required to integrate a new Transaction Type with AME.
Attributes
Within AME, Attributes can be defined as business variables which represent the value of an element in a transaction. For example, in the case of an invoice approval, a typical attribute would be the supplier name, or the invoice value. When defining the business rule, the attributes that are available to you will help define the rule itself and it’s implementation within AME. The reason for this is that the value of an Attribute for a transaction is usually evaluated as part of the rule in order to determine whether the condition has been met or not – for example, is this invoice worth more than £500? Within AME, Attributes can be created as static (where they have a constant value which remains the same for every transaction associated with the Attribute), or as dynamic (where they use a SQL query to determine the value of the Attribute at run time). Most Attributes that are used within AME are dynamic.
Within AME, there are different types of Attribute available to you:
- Strings can be alphanumeric and have a maximum length of 100 characters.
- Numeric attributes can have any numeric value that is acceptable in PL/SQL, including decimals and negative numbers. When using a numeric Attribute within AME, the number must be converted to a canonical form – within the FND_NUMBER package there is a function NUMBER_TO_CANONICAL which will do the conversion for you.
- Currency Attributes are used when the organization is using multiple currencies. This allows Oracle to perform currency conversions when retrieving the Attribute value. If currency Attributes are used, the SQL query which retrieves the value must include the numeric column, currency and conversion method. Additionally, any AME conditions which use currency Attributes must include a condition for EACH CURRENCY that the transaction might use.
- Boolean Attributes can only have a valid value of true or false. Any dynamic Attributes which are defined as Boolean MUST return one of these two states – NULL is not a valid value in an AME Boolean Attribute. When using Boolean Attributes, AME provides a format string which should be used – AME_UTIL.BooleanAttributeTrue and AME_UTIL.BooleanAttributeFalse.
- Date Attributes are commonly used within AME – for example the invoice date, shipping date, and so forth. Again, AME is particular with the format and requires all date Attributes to be in the format YYYY:MON:DD:HH24:MI:SS. There is a format string again provided in the AME_UTIL package – AME_UTIL.versionDateFormatModel which can be used to return a date in the required format.
Read the rest of this entry »
Posted in Functional, Oracle | 3 Comments »
February 4th, 2010 Matt
Recently, I’ve been asked from a number of places about Oracle’s Approvals Management Engine, or AME, so in the next few blog posts, I’ll be taking a look in more detail about what it is and what it can do for you and your organization.
AME is an “easy” way for a business analyst / functional consultant to define business rules for transaction approvals within eBusiness Suite. Not all applications modules support AME, however, in which case you are back to the age-old bespoke method of identifying approvers and including custom logic to ensure that the right people are included within the approvals process. Note that I have used inverted commas for the word “easy” – AME provides the opportunity to include business rules which can vary widely in complexity.
In this post, I’ll be looking at the components of AME which are required for configuration, and in later posts I’ll move onto some practical examples from within iRecruitment and Financials.
AME Basics
As I said earlier, the purpose of using AME is to implement specific business rules within the framework of the application to manage the approval of a transaction. This can always be done outside of AME (and for some modules, this is still a requirement!), but if the approvals process can be captured within AME then this makes for a more straightforward implementation which (theoretically at least) is easier to maintain over the long-term. When approval is sought, AME uses Workflow notifications to inform the approver that they need to action the request, and to capture their response.
AME (as I said earlier) allows you to implement rules of differing complexity – for example, any invoices which are over £500 must be approved by the requester’s supervisor; all vacancies created in iRecruitment must be approved by Bob in HR; and so forth. Many organizations, however, have much more complicated – for example, any invoice which is matched to a purchase order and has any lines which are over £5000 and include heavy machinery must be approved by the Operations Manager and his immediate supervisor (or the next available supervisor with the appropriate authorization limit). The flexibility that AME brings means that the same method can be adopted for any of these requirements.
So, why bother with AME?
You can already build all of this through custom code – and in versions of the eBusiness Suite that were availably prior to AME, that is what most organizations did. However, there are some clear advantages of managing the approvals process using AME over using bespoke software.
Firstly, in many cases, business rules can be defined and implemented without the need for any code. Now that’s a big one, so I’ll say it again – IN MANY CASES, BUSINESS RULES CAN BE IMPLEMENTED WITHOUT THE NEED FOR ANY CODE. Less code means less things to maintain, and less things to go wrong (assuming that the functional configuration is correct and the code is always the thing to go wrong, but we’ll not go there in this post!!).
Secondly, if there are already hierarchical structures defined in the application, then AME can leverage these as standard – again, there is no need to write custom code to find the next available approver, since AME does it automatically.
Another advantage of using AME is that if there are specific requirements to route an approval to a specific group of people or an individual, then AME provides the person making the functional configuration with the ability to setup specific hierarchies or approval groups which can be used to determine where to route the approval.
The last main benefit (and it’s a good one!) is that AME has the ability to respond to any changes in the approvals process whilst the process is still going on. This includes, for example, a change in the approvals hierarchy (which can be included fairly easily within custom code) but also if the business rules themselves are modified during the process, or even if the values of the transaction themselves change during the process – now that’s clever! Every time an approver for a transaction responds with an approval, AME checks the rules as they stand at that point in time, and rebuilds the approver list to determine who the next approver should be. So, let’s take the simple example above where if the invoice is over £500 then the supervisor must approve the invoice. An invoice for £1500 is created, AME checks the business rules and notifies the supervisor. The business analyst then decides that if the invoice is over £1000, it requires three levels of approval, and so makes the change within AME. When the supervisor responds to the notification, AME rebuilds the approval list using the new rules, identifies who the next approver should be, and then routes the transaction to them for approval.
That’s the end of my very quick overview of what AME is and why you should use it – in the next post, I’ll go into the components of AME and how they work together.
Posted in Functional, Oracle | 4 Comments »
January 4th, 2009 Matt
I was chatting with someone on a current project this week, who was asking about the best ways to get into Oracle eBusiness Suite. He was just after some kind of sandpit environment to play about in – he’s fairly technical but hasn’t got much Oracle exposure, and almost no eBS exposure.
So I said “oh, you want to have a look at Solution Beacon – they’ve got some instances.” His immediate response was “oh, I can’t remember the link, but I’m sure that I’ll read about it in your blog…”
So, here it is!
Solution Beacon have a few 11i and R12 eBusiness Suite systems running, that you can play about in – they refresh them periodically, and there’s no database login, but for finding your way around Oracle Apps, it’s a good starting point – plus you don’t need to install your own sandpit area to play in!
The links to the 11i environments can be found here.
Posted in Functional, Oracle, Technical | No Comments »
