The Oracle Application Framework (OAF) provides a mechanism for us to provide a substitute definition for a View Object, With this mechanism, any time the Framework asks for the UnitOfMeasuresVO it will actually get our personalised version. The easiest way to create a personalisation of this type is to use the appropriate version of JDeveloper. You cannot use the mainstream version of JDeveloper from OTN – you need to download one that has the correct version of JDeveloper that has the OA Extension built-in (see MOS Note 416708.1 for more details).

For this article the target environment is an R12.1.3 environment, so I have JDeveloper 10g on my desktop. Once that is setup, we also need to copy the current View Object definitions locally as well. As mentioned in Part 1, the VO that we are interested in is oracle.apps.ap.oie.server.UnitOfMeasuresVO, which resides in the server-side folder $JAVA_TOP/oracle/apps/ap/oie/server. Copy the whole contents of this folder to equivalent folders under your JDeveloper myprojects and myclasses folders (which are subfolders of your JDEV_HOME).

Something else that you’ll need from the server is the DBC file for the EBS environment. This can be found in the $FND_SECURE directory and should be copied to the local JDEV_HOME\jdev\dbc_files\secure folder:

Now you can start JDeveloper and create a new Workspace (in JDev 10g these are actually called Applications, but the OA Extension still refers to Workspaces). Select File, New… from the menu and choose the Workspace configured for Oracle Applications option:

Enter some appropriate values for your environment, making sure that the Add a New OA Project is ticked. When the New Project Wizard is displayed, give the Project a suitable name. You will need to enter a value for the Default Package, but for this solution the value is not used:

On Step 3 of the Wizard, you need to select the DBC file that we downloaded earlier and enter the username and password of an EBS user. You can leave the Responsibility fields as default, as we are not actually creating a runnable project; we are just using JDeveloper to create XML and Java Class files:

Once the project is created, you will see that the files we copied from the server are now visible under the Application Sources folder. Right click on one of the folders and select New View Object…

The name of the Package that you enter on the Create View Object dialog is important. The VO that we are extending is in the package oracle.apps.ap.oie.server; we need to replicate the same path, but include a short name to indicate your organisation – for us we add pcl:

The next Step is the most important – here we can override the SQL from the original VO. In the previous article, Ian suggested a single addition to the WHERE clause, but just in case this VO is used in more than one screen (ie: with other Lookup Types), I have added some extra clauses. Once the SQL has been entered you should validate it using the Test button:

Some versions of the OA Extension have a slight issue with some older XML VO definitions. On Step 6 you may see that the Query Column Type is not correct, showing a value starting $none$; these need to be changed to reflect the datatype of the columns being selected:

On the last Step of the Wizard ensure that the Generate Java Class checkbox is ticked under the View Row Class heading – these Java classes are not necessary for BC4J, but they are required to ensure that we adhere to the Oracle Applications Development Standards:

Once the Wizard has completed it’s code generation process, you can see our new VO:

Now we need to ensure that the Framework knows to substitute in our new VO when the original is requested. This is done on the Project Properties dialog. Once displayed, find the Business Components, Substitutions page:

Under the Available heading we need to select the VO that we are overriding and on the other side we select the VO that is being substituted in:

Finally, we need to build the Project. This compiles the Java sources into CLASS files and copies them and the XML definition files from myprojects into the myclasses folder structure:

We’ve completed everything we need to do in JDeveloper – now we need to get the files back over to the right places on the Application server. We need to copy all the files in myclasses\pcl\oracle\apps\ap\oie\server to $JAVA_TOP/pcl/oracle/apps/ap/oie/server:

Finally, we need to upload the substitution information into the Metadata Store (MDS). This is stored in a file with a JPX extension. There are Java helper classes available on the server to help you to upload this:

And that’s it! If we log into EBS and go to i-Expenses, we can see that the UoM drop-down list now only has the single value that we want to display:

To confirm that the Framework is using our VO and not the original, we can click on the About this Page link and expand the Business Components References Details section.

About half way down the list of Objects we see the reference to our VO. If we click on the VO name we are shown the details of the VO and we can confirm the SQL behind the VO is the SQL that we entered earlier:

Obviously, this type of Personalisation is more complicated than the type of Personalisation that can be done using the web user interface. However, the most important thing is that this is a Personalisation and not a Customisation and so fully supported by Oracle.

Why do I see Swedish Miles?
   or
Can I just have Miles?
   or
Can you remove all values in the Unit of Measure list and just keep the one that is relevant for our T&S policy?

For users in other regions, the same question may well include the desire to remove Miles (e.g. regions in mainland Europe) or Kilometers (e.g. UK). The screenshot below shots the seeded view of values a user is presented with when entering a mileage claim.

and then the Expense Report line details:

The seeded list of values for Mileage UOM’s are contained within the Payables Lookup set called OIE_DISTANCE_UOM. This is a system lookup set and therefore the values cannot be disabled or end dated. Meanings and descriptions can be updated but this does not change the fact that the values will remain and will continue to be referenced when entering an expense claim both at the expense line and expense line detail levels.

So how does one reduce this list values to include only the mileage UOM’s that are relevant? This article will explain how to remove the Swedish Miles and Kilometers values to leave a default read only value for miles.

Expense Report (ER) Lines

To remove/reduce the list of values on the expense report line, this can be achieved by configuring the user interface using an OA Framework personalisation of the ER lines html page. Before any personalisation’s are possible the profile option ‘Personalize Self-Service Defn‘ has to be set to ‘Yes’. It is advisable to set this at the user level for the person carrying out the personalisation to avoid the rest of the business seeing the personalised region links within the application while this work is being performed. The next steps are as followed:

1. Create an expense report ensuring you stop at the point where the unit of measure of displayed for a mileage expense line
2. Click the ‘Personalize Page‘ hyperlink at the top right corner of the html page
3. Within the Personalize page, use the search criteria and choose the style of ‘Message Choice’
4. Enter ‘Unit of Measure’ within the Title/Prompt/Text search field and click GO
5. Click the personalize pencil icon against the row which contains the ‘Message Choice: Unit of Measure’
6. Once you have decided at which level to set the personalization, i.e. site, organisation, responsibility etc, set the Read Only value to ‘true’ (shown below)
7. Click Apply
8. Navigate back to the ER lines and check the results. You should now be presented with a read only value for Miles where the list of values is no longer a selectable list.

Expense Report (ER) Line Details

Unfortunately, no personalization is available for the expense line details. During a recent i-Expenses implementation, I raised an SR with Oracle on this very subject. The following customization is recommended by Oracle My Support:

Modify the $JAVA_TOP/oracle/apps/ap/oie/server/UnitOfMeasuresVO.xml by adding the following condition in the select statement:

and lookup_code in (‘MILES’) –valid values are ‘KM’,'MILES’,'SWMILES’

Note: Include the ones that you wish to see in the poplist.

Conclusion

The solution above combines a personalisation and a very simple customisation. Any business adopting this solution should pay attention to future patching and upgrade strategies and understand how any changes may impact this solution.

Adopting the ER Line detail customisation achieves the desired result; however, customisations should always be the last resort after all other possibilities have been investigated. At PCL we have found a better solution to the requirement of amending the Mileage UoM for the ER line details. See Part 2 of this blog article for more information.

The functionality offered by Oracle Projects is somewhat limited in scope; only Procure-to-Pay transactions (requisitions, purchase orders and supplier invoices) are subject to budgetary control. Consider the following scenario:-

• A project has an approved cost budget of £1m
• £0.5m of expenditure is charged against the project through Transaction Import (e.g. an interface from an external system)
• Budgetary control in Payables and Purchasing will still perceive that there is £1m budget available to spend; only amounts charged to the project through Payables and Purchasing will be included in the budgetary control calculations

With the above in mind, this does not exactly offer a great degree of control over the budget! The only way that I see this functionality being of any use is if either:-

1. All project costs will be sourced from the Procure-to-Pay process
2. The project budget is split by task or resource, ring-fencing the Procure-to-Pay element of the budget

As per Barry Crawley’s post, rather more limiting is the fact that the aforementioned functionality is only available for legacy project budgets, and not financial plans. Due to the existing shortcomings of the functionality, it is no surprise therefore that Oracle have made no apparent effort in porting it to the financial plan model in 11i or R12.1.

So, what are the other options? For those organisations who perceive that budgetary control is a must, there is a little known application called Oracle Grants. Oracle Grants is largely built on the Oracle Projects costing and billing product; to the extent that the two applications cannot co-exist within the same Operating Unit.

Oracle Grants offers the same degree of real-time budgetary control for the Procure-to-Pay applications, but also takes into account all other project expenditures (from all other transaction sources). There is, however, one big drawback. The budgetary control approach for non-Procure-to-Pay expenditure only works on a reactive basis. The budgetary control routines in Oracle Grants have simply been added as a “wrapper” to the Oracle Projects Costing concurrent programs. This means that expenditures are only funds checked when they have already hit the project (and are submitted for cost distribution). Again, this hardly offers a great degree of control over the budget.

Having spent many years working with both Oracle Grants and Oracle Projects customers, there is definitely a perceived need for budgetary control. Personally, I would like to see this functionality brought into the core Oracle Projects application, where all project expenditures are funds checked at the point of entry (or in the very least, before they are interfaced to the Projects ledger).

One pertinent question to ask of any budgetary control mechanism, whether in Oracle Projects or Oracle Grants, is what happens to expenditures that do not pass funds checking? If a project has got to the stage where a requisition is being entered, it is quite plausible that the goods or services being procured are required for the project to progress. If this is the case, does budgetary control actually prevent the funds from being spent, or does it merely delay the process? More alarmingly, if the items being procured are project critical, does budgetary control force the expenditure to be charged to a different project? The danger of the latter of course is that the true cost of a project can never be calculated; the system audit trail of which project a cost is actually attributable to is lost at point of entry.

The answers to some of the above questions may depend on the culture within an organisation, and more importantly, the sector in which they operate. In some industries for example, contractual flexibilities permit expenditure to be booked across different projects. This obviously still makes it very difficult to reflect the true cost of an individual project.

In extreme circumstances, budgetary control functionality could actually be detrimental to an organisation. It is possible that an over reliance on budgetary control could, over time, replace proactive management of project budgets. Whilst attempting to use budgetary control to mitigate overspends, the actuality may be that a “spend until the system stops it” culture is embedded. Under such circumstances, the emphasis on closely monitoring project balances may be relaxed, with the apparent safety of budgetary control as a backup. However, it is only when a funds checking failure is encountered that the business realises that a project is in trouble. By which time of course, it may already be too late.

Whilst the above scenario would only occur in extreme cases, I think that it highlights that budgetary control should never be seen to replace, in full or in part, good project management.

Moving on, I would like to discuss an alternative viewpoint. Organisations from around the world that use Oracle Projects, across many industry sectors, manage to survive without any budgetary control functionality. Perhaps said organisations are desperate to see the current functionality extended in R12 and we are all suffering in silence! However, it is more likely that organisations survive without budgetary control in Oracle Projects is because they do not need it.

For an organisation to successfully operate without budgetary controls, I believe that the following four elements need to be in place:-

1. Reporting

Precise, accessible and timely project reporting is required so that project managers and administrators are empowered with a clear view of spend to budget to forecast, throughout the project lifecycle

2. Business Process

 Business processes should clearly state what needs to be done, and what is permitted, at each stage of the project lifecycle by whom. Well structured project phases, regular project reviews and approval workflows should all help to ensure that any problems are flagged up as early as possible

3. Review and Adapt

If an overspend does occur, a review process should ascertain how and why it has happened. Measures should then be put in place to prevent any repeat occurrences

4. Accountability

Ultimately, the successful management of project budgets relies on accountability. Without named individuals being accountable for project budgets, overspends will be difficult to mitigate

Obviously there will be other extenuating factors that can affect a project, but if the above four elements are in place, is there really any need for automated budgetary control? Perhaps this is why it appears to be a low priority for future Oracle Projects development. Perhaps the best practice is to enforce good project management, and not to be over reliant on systems doing it for us.

I hope you have found this article interesting. I would love to hear other people’s experiences with (or without) budgetary control in Oracle Projects and Oracle Grants. I would be especially interested to hear from anyone using Oracle Grants without budgetary control.

There are two related blogs on this site which I recommend also reading:-

http://www.projectedconsulting.com/index.php/community/blog/2010/10/funds-checking-for-projects-financial-plan-model-not-on-current-r12-roadmap/

http://www.projectedconsulting.com/index.php/community/blog/2009/05/funds-checking-budgetary-control-and-budget-integration-with-gl-for-oracle-project-management/

The process instance would fail with:

Authenticate

[2011/03/31 08:34:52] Reauthenticating with P6 EPPM

[2011/03/31 08:34:52] P6 session could not be retrieved!

[2011/03/31 08:34:52] “{http://xmlns.oracle.com/ABCSImpl/P6EPPM/Core/GetSession/V1 AuthenticationException” has been thrown

After a long process of trying to track down the problem I discovered a typo in the Oracle documentation for deploying Primavera WebServices (OraclePrimavera® P6™ WebServices Administrator’s Guide Version 7.0)

On Page 26 Step 18 states:

18 Before starting P6WebServices, add the following JVM option to the startWeblogic startup script:

……..

OnLinux:

JAVA_OPTIONS=”${ SAVE_JAVA_OPTIONS} -Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl -Djavax.xml.soap.SOAPConnectionFactory=weblogic.wsee.saaj.SOAPConnectionFactoryImpl”

This has a typo in it. The space before the SAVE_JAVA_OPTIONS shouldn’t be there. If it is it will make the Web Service error. The correct line should be:

JAVA_OPTIONS=”${SAVE_JAVA_OPTIONS} -Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl -Djavax.xml.soap.SOAPConnectionFactory=weblogic.wsee.saaj.SOAPConnectionFactoryImpl”

The install covers 3 different sections – Installing the BI Publisher itself, installing the BI Office plugin and also setting up the Publisher Scheduler.

Note the WebLogic install that this was completed on was installed in development mode. If you are working on a production install you will need to lock and edit the confguration and release where necessary.

1 BI Publisher Install

Download the standalone version of BI Publisher from e-delivery for your platform (V16389-01.zip).

On the application server create a directory for the install

$pwd

$/u01/app/oracle/product

$mkdir xmlpserver

Copy the zipped software into a temporary directory and unzip: 

$cp V16389-01.zip /tmp

$unzip V16389-01.zip

This results in a tar file. Untar this file:

$tar –xvf bipublisher_aix_101341_1of1.tar

Find the latest BI Publisher patch from My Oracle Support – note 797057.1 is a good reference for this. At the time of install the latest was 10623023.

Download the patch and unzip it. This contains a new version of the application which is required.

Copy the non-oc4j deployment war file supplied in the patch to the newly created directory:

$cp /tmp/10623023/non-oc4j/xmlpserver.war /u01/app/oracle/product/xmlpserver/

Unzip the war file:

$cd /u01/app/oracle/product/xmlpserver/

$unzip xmlpserver.war

Back up the existing Bi Publisher repository:

$cd /u01/app/oracle/product/OracleBI/xmlp/

$mv XMLP XMLP_bck

Copy the standalone XMLP repository from the standalone software to main install area:

$cd /tmp/<your platform>/Oracle_Business_Intelligence_Publisher_Standalone/manual

$cp –R XMLP /u01/app/oracle/product/OracleBI/xmlp/

Update the xmlpserver configuration file to point to the new XMLP repository just created:

$cd /u01/app/oracle/product/xmlpserver/WEB-INF

$vi xmlp-server-config.xml

Edit so that the file path points to the new BI Publisher repository:

<?xml version="1.0" encoding="UTF-8"?>
<xmlpConfig xmlns="http://xmlns.oracle.com/oxp/xmlp">
<resource>
<file path="/u01/app/oracle/product/OracleBI/xmlp/XMLP"/>
</resource>
</xmlpConfig>

Deploy BI Publisher in WebLogic

Log into the WebLogic administration console:

http://<server>:7001/console

(Assuming your Weblogic server is on port 7001)

Click on the Deployments link and select the xmlpserver which was previously deployed, click on the delete button:

Click on deployments again and the xmlpserver application should have been removed. 

Weblogic caches the deployment details so this needs to be removed before redeploying if the delete didn’t remove it. If this in not done WebLogic is likely to error when trying to redploy the application.

Rename or remove the cache directory /u01/app/oracle/product/bea/user_projects/domains/<your domain>/servers/<WLS server name>/tmp/_WL_user/xmlpserver

Back in WebLogic adminconsole, click on install to install the new application and select the xmlpserver directory containing the application, then click next:

Select to install it as an application:

On the next screen check the button to make the deployment available from the directory:

Then click Finish on the next screen to get to the settings page. Check these and press save:

Click back on the deployments page and check the deployment succeeded:

Test a login:

http://<server>:7001/xmlpserver

Username/password Administrator/Administrator

This should bring up a browser which looks similar to below:

2 Deploy BI Office application

The next step is to deploy the bioffice application that desktop plugin’s will use:

Make a directory to place the application in:

$cd /u01/app/oracle/product
$mkdir bioffice

Copy the web application (bioffice.war) from /u01/app/oracle/product/OracleBI/office/server to the new directory and unzip.

$cp bioffice.war /u01/app/oracle/product/bioffice
$cd /u01/app/oracle/product/bioffice
$ls
bioffice.war*
$unzip bioffice.war

Update the configuration file to point to the Analytics URL:

$cd /u01/app/oracle/product/bioffice/WEB-INF/
$vi bioffice.xml

      Change <property>http://localhost/analytics/saw.dll</property>

To

<property>http://<your server>:7001/analytics/saw.dll</property>

Deploy the app in Weblogic

Undeploy existing application by deleting once selected (if it exists):

Remove the cache of the deployment by renaming or removing the directory /u01/app/oracle/product/bea/user_projects/domains/<your domain>/servers/<your server>/tmp/_WL_user/bioffice

To install the new version click Install on the deployments page:

Select the bioffice directory and click next:

Install as an application, click next:

Make it accessible from the directory and click finish:

Make sure application is active in the deployments page:

3   Setup BI Publisher Scheduler

 Configure WebLogic to use TopLink libraries:

$cd /u01/app/oracle/product/bea/user_projects/domains//bin
$cp startWebLogic.sh startWebLogic.sh.bak
$vi startWebLogic.sh

Change the section which starts weblogic to (added sections in bold):

echo "starting weblogic with Java version:"
${JAVA_HOME}/bin/java ${JAVA_VM} -version
if [ "${WLS_REDIRECT_LOG}" = "" ] ; then
echo "Starting WLS with line:"
echo "${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} –Dweb logic.Name=${SERVER_NAME} -Djava.security.policy=${WL_HOME}/server/lib/weblogic.policy -Dtoplink.xml.platform=oracle.toplink.platform.xml.jaxp.JAXPPlatform ${PROXY_SETTINGS} ${SERVER_CLASS}"
${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} -Dweblogic.Name=${SERVER_NAME} -Djava.secur ity.policy=${WL_HOME}/server/lib/weblogic.policy
-Dtoplink.xml.platform=oracle.toplink.platform.xml.jaxp.JAXPPlatform ${PROXY_SETTINGS} ${SERVER_CLASS}
else
echo "Redirecting output from WLS window to ${WLS_REDIRECT_LOG}"
${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} -Dweblogic.Name=${SERVER_NAME} -Djava.security.policy=${WL_HOME}/server/lib/weblogic.policy
-Dtoplink.xml.platform=oracle.toplink.platform.xml.jaxp.JAXPPlatform ${PROXY_SETTINGS} ${SERVER_CLASS} >"${WLS_REDIRECT_LOG}" 2>&1
Fi

Create a tablespace to hold the scheduler tables, in SQLPLUS:

create tablespace BIPUBSCHED
datafile '/u02/oradata/devobi01/BIPUBSCHED01.dbf' size 10G
extent management local autoallocate;

Create a user in the datawarehouse to hold the scheduler tables and grant necessary privileges, again in SQLPLUS:

Create user bipubsched identified by xxxxxx
Default tablespace BIPUBSCHED
Temporary tablespace temp
Quota unlimited on BIPUBSCHED;
Grant connect, create table to bipubsched;

Create scheduler tables

Log into BI Publisher as Administrator (password Administrator)

In the Admin tab select Ssystem Maintenance -> Scheduler Configuration

Enter the relvant infomartion and test the connection:

Now install the schema by clicking the ‘Install Schema’ button – when finished a confirmation message is displayed just under the tabs:

This completes the install of BI Publisher. There are further steps to define your data connections and other steps dependant on your implementation.

The application can be access at htpp://<server>:<port>/xmlpserver

Errors hit

One of the main errors that was encountered was the following Java stack when trying to run the scheduler. The solution was to apply the latest BI Publisher patch as described in the steps above. 

oracle.apps.xdo.servlet.scheduler.ProcessingException: Error occurred while scheduling the job.

         at oracle.apps.xdo.servlet.ui.scheduler.SchedulerServlet.scheduleJob(SchedulerServlet.java:1927)

         at oracle.apps.xdo.servlet.ui.scheduler.SchedulerServlet.doPost(SchedulerServlet.java:293)

         at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)

         at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

         at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)

         at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)

         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)

         at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)

         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)

         at oracle.apps.xdo.servlet.security.SecurityFilter.doFilter(SecurityFilter.java:94)

         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)

         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3496)

         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)

         at weblogic.security.service.SecurityManager.runAs(Unknown Source)

         at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180)

         at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086)

         at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406)

         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)

         at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

Originally I hit problems when trying to redeploy the application. This came due to the cache not being removed when the old deployment was deleted. The way around this was to delete the cache directory for the app (as described above).

While trying to use the plugin’s for Excel on a desktop there was an issue with the locale. The workaround to this was to copy C:\Program Files\Oracle\BI Publisher\Analyzer for Excel\config\en-US.xlf and rename it as en-GB.xlf.

In R11 and earlier releases, the sub ledgers are the source of reference for the account coding of Project transactions via Distributions. With the introduction of Subledger Accounting (SLA) in R12, this is no longer the case. Subledger Accounting is a rule-based accounting engine that defines how journal entries are generated for subledger transactions in Oracle E-Business Suite. All subledger accounting is managed by SLA, i.e. journals are not posted directly to the GL from a subledger but are now “processed” by and through SLA. SLA does not exist as a separate discreet module. It is an underlying engine that provides a set of functions, supported by a new schema and underlying tables, that will allow configuration and maintenance of accounting rules. These are accessible within the subledgers as additional menu functions.  

Subledger Accounting Menu Functions

For Projects, the Subledger Accounting inquiries appear under the new heading Accounting Inquiries and include:  

• Accounting Events
• Journal Entries
• Journal Entry Lines

The Setup menu options for SLA have also been added to the Setup Navigation branch of the menu.  

Subledger Accounting Setup Menu

The SLA Accounting Process

As the subledgers record new transaction entries and adjustments, and validate them, they become eligible for accounting by SLA. Eligible transactions are processed by the running of SLA-specific concurrent requests. These requests will vary from subledger to subledger but ultimately, SLA accounting is completed by performing two steps.  

The first step is for SLA to determine what subledger transactions are eligible for processing and to create entries in the SLA tables to represent them. No accounting is created. In Projects, valid  transactions will include those that have been processed via cost “Distribution” and revenue  “Generation” concurrent requests and would be eligible for the PRC: Interface to GL processes of earlier releases. One SLA “Event” entry will be created for each transaction.  

In Oracle Projects, examples of these SLA concurrent processes include:  

• PRC: Generate Cost Accounting Events
• PRC: Generate Cross Charge Accounting Events
• PRC: Generate Revenue Accounting Events

There is a one-to-one relationship between a subledger transaction and an Event entry. For example, each miscellaneous transaction line in Expenditure Inquiry will have a corresponding Event in SLA, though there may ultimately be several journal lines produced as a result of that single event. Note that after running one of these first requests, there are no accounting entries for the new Events in SLA.  

Subledger Accounting Events

The second stage will generate accounting entries based on the rules defined in SLA for the entries or “Events” now held in SLA. Note that although Projects distribution and draft revenue generation processes will have generated elements of the accounting entries, these are not necessarily used by SLA, unless the SLA rules indicate they should be. SLA rules could be defined that ignore the results produced by AutoAccounting and instead proceed to generate journal entries based on entirely different criteria.  

The generation of accounting entries is done by running a second concurrent request. For Projects, this is PRC: Create Accounting. This request actually calls an executable that is shared across the subledgers, i.e. each subledger will have it’s own concurrent program to call, but they will all call the same executable. This second request will do the following:  

1. Collect relevant data on transactions from the core subledger tables
2. Determine  accounting attributes based on the collected data
3. Determine  Code Combination IDs (CCID) based on the rules defined within SLA
4. Create journal lines based on the Journal Definition (part of the SLA rules)
5. Create lines in SLA’s Accounting Entry Header and Lines tables (XLA_AE_HEADERS and XLA_AE_LINES).

When this second request is submitted, the user will specify the mode it should be run in. In “Draft” mode, the accounting is generated for user review but is not eligible for transfer to the GL. This allows users to review all the accounting without fear of the results being posted to the GL. The request must be submitted in “Final” mode for posting to the GL to be possible.  

Subledger Accounting Transactions

Below is an illustration highlighting the concurrent requests and components created for each:

Subledger Accounting Components

Advantages of SLA

• Prior to SLA, the method of generating accounting for a transaction varied greatly from subledger to subledger. SLA allows a common set of rules to be defined that can be used across the subledgers. All transactions that result in accounting in the GL will be represented in SLA before accounting rules are applied. It should be noted that the seeded SLA rules will expect to find account code distributions in the same locations as they would have been prior to the introduction of SLA and will fail without this. For example, in Projects, AutoAccounting rules will still need to be configured and the values generated by the execution of these rules, will be used by SLA. In effect, the out-of-the-box rules of SLA expect the account codes to have been captured/generated by the subledgers.
• As a centralised repository of subledger transactions for accounting, SLA maintains full relationships between GL postings and the subledger sources. This also supports the creation of different accounting entries in different reporting ledgers from a single transaction, e.g. to accommodate statutory and regulatory requirements.
• SLA allows users to define entirely new sets of accounting rules or “Accounting Methods”. Seeded rules that come pre-installed cannot be updated and are assigned the owner “Oracle”. However, copies can be made and these are “User” owned. This has been done in order to allow users to create their own logic while protecting the integrity of seeded configuration for upgrades, i.e. an upgrade process will not fail because expected seeded entries are missing/have been modified.
• SLA provides users with the ability to immediately create, view, transfer and post accounting in GL when transactions are entered into subledgers such as AP rather than wait for the transactions to be processed in the next scheduled concurrent request. Online and offline accounting share accounting rules and validations. There is no logical difference. Draft mode is available to “online” accounting and may be used to review the accounting. This allows users to initiate the generation of accounting lines in SLA directly from within the subledger, rather than needing to run a concurrent request. When run in “draft” mode, the generated accounting journals will not be eligible for posting to the GL but will allow the user to view what the journal entries will be based on the current set of SLA rules. When processed in “Final” mode, journals will be eligible for posting to the GL from SLA. This is similar to running the distribution processes from the transaction forms rather than navigating to the concurrent requests form.  This would allow the user to view the SLA-based accounting results without navigating away from the transaction screens.
• Subledger Accounting provides users with the option to create accounting entries in “draft” as well as “Final” mode. When in “draft”mode, the accounting entries will be generated but will not be eligible for interfacing to the GL.  This allows users to review the accounting without fear of errors being posted to the GL. As rules in SLA change to meet changing business requirements, this mode will allow users to test and confirm the accounting results before “final” mode is used. Draft mode is a review mode. Final mode will generate accounting entries that are eligible for transfer to the GL. Users are not required to generate in draft mode and can create accounting in Final mode directly. Modes and override options can be set during the configuration of Subledger Options.
• SLA can store substituted disabled accounts on SLA journal lines for audit and reconciliation purposes. When an account is disabled, users can continue to create accounting for transactions that include the disabled account without generating an error based on the substitution. This could allow for date-dependent values to be used and prepared in advance of coding changes, and can ensure that the valid codes are used.
• SLA allows users to customise their view of the accounting by using the attributes of the journal entry. Users may also define and save searches. Embedded flows support two-way drilling between journal entry headers, journal lines, T-Accounts and Transaction data. Note that the distribution line entries of the transaction in the original ledger are not updated by SLA. These entries are considered to be “default” and SLA may use or ignore them, according to the rules defined in the accounting engine. For example cost distribution lines for expenditure items in Oracle Projects will account using rules in Auto Accounting, but SLA may create different accounting for these. Therefore the accounting on these cost distribution lines is not necessarily what ends up in the GL. One scenario where this may be useful is where expenditure items are transferred from one project to another. If the original transaction was accounted in for example 2010 and the transfer took place in 2012 then the accounting produced in Oracle Projects by standard AutoAccounting is as follows:
  • Reversal expenditure item – debit and credit are copied from the original line
  • New expenditure item – debit and credit are derived from AA rules as defined and assigned at the point the transfer is process
• When these reversal and new transactions go through SLA both lines will be accounted in SLA and the reversal line will not necessarily have the same accounting as the original line that it is reversing. A classic scenario is where AA references a lookup set where the mapping has been changed since the original transactions was accounted.
• Using the Diagnostics framework, Subledger Accounting will allow users to view the transaction information used to create sub-ledger journal entries. Diagnostic information is also shown as an HTML Report.
• SLA rules can be date-dependent, i.e. dates can be specified to define the period during which the rule should be used. This will allow planned changes to be prepared in advance of the date in which they go into effect.

Disadvantages of SLA

• Now there are an additional set of database tables for SLA, the potential issues in reconciling GL to the subledgers increase, i.e. you now have to:
  • Reconcile GL to SLA, which should be straight forward, but still has to be done
  • Reconcile SLA to the subledgers – the existing problems between for instance AP / GL / Projects may still exist, and therefore reconciliation is still important

This will come as disappointing news to those customers who currently use funds checking and wish to migrate to financial plans, as well as those evaluating Oracle Projects who require strict control of expenditure as well as financial plan flexibility.

Product strategy added that the requirement for funds checking will be re-evaluated when defining the scope for post R12.2 releases.

The issue depends on how your budgets are phased, and only manifests itself if budgets are being entered by date range (as opposed to period, whether that be GL or PA).

The problem is that budget lines entered by date range are catered for differently between the two applications. In the E-Business Suite, budget line amounts are allocated to periods on a linear basis (including weekends). Conversely, Project Analytics takes a much more simplistic approach, and budget line amounts are reported in the period in which the line start date falls. To make this clear, consider the following budget scenario which has been phased by date range:-

Budget Line   Start Date     End Date        Amount
1             01-JAN-2010    28-FEB-2010     1,000
2             01-MAR-2010    03-MAR-2010     250
3             04-MAR-2010    27-APR-2010     1,400
4             27-APR-2010    30-APR-2010     500

Assume that GL/PA periods are defined as calendar months with the name format Jan-10, Feb-10 etc.

If we were to report Period-to-Date (PTD) figures in the E-Business Suite, the following linear formula applies to the budget line amounts:-

(number of days within the budget line range that fall in the reporting period × line amount) ÷ number of days in the budget line range

As mentioned above, in Project Analytics, PTD amounts are reported based on the period in which the start date of the budget line falls.

The above scenario gives the following PTD results:-

Period     EBS       Project Analytics
Jan-10     525*      1,000
Feb-10     475       0
Mar-10     963       1,650
Apr-10     1,187     500
Total      3,150     3,150
* e.g. (31 * 1000) / (31 + 28) = 525 (approx)

As you can see, only the budget lines with date ranges that span across multiple periods are affected (lines 1 and 3).

This has been addressed in the recent release of 7.9.6.2 of OBI Applications and a new logical fact table has been added. To quote the release notes:-

A new logical table, Fact – Project Budget Linear Spread, has been created that contains Budget metrics built using a Linear Spreading logic in the business model and mapping layer. However, the new metrics are not exposed in the presentation layer. You can either replace the existing Budget metrics in presentation layer with the new ones (the same metric names are used in the old and new logical Budget fact tables), or create a new subject area to expose the new metrics. The first option enables you to reuse the existing reports with Budget metrics without any modification.

It is interesting that Oracle have left the option of whether to use the new fact table down to the customer, as I can not think of any scenario where I would wish date ranged budgets to be displayed as per the example above.

Project Analytics sees some updates in the latest release, most notably the introduction of a project commitments subject area. The full list of updates to Project Analytics are:-

• New Project Commitments Subject Area for Oracle EBS 
• Updates to Universal Adapter for Oracle Project Analytics 
• Configuration Update for Project Customer for Oracle EBS 
• My Oracle Support Technical Note on How to Configure RPD if the Cost Aggregate Grain is Set to Period or Year 
• New Dimension for Project Budget and Forecast Fact 
• Linear Spread Metrics for Project Budget Fact

A full summary of the new features across the 7.9.6.2 OBI applications can be found on oracle.com here, with the Project Analytics updates here. No doubt that a number of bug fixes have also been included, as previously alluded to in My Oracle Support.