The Feature

How to Override Asset Depreciation

October 3, 2007 on 8:39 pm | by Marian Crkon | In Feature of the Week, How To Guides | 3 Comments |  Print |  Email

I am not actually sure when this feature became available but, to my delight, I found out today that you can retroactively override existing depreciation amounts for standalone and group assets calculated by Oracle Assets. Hence, depreciation override is my “feature of the week” this week.

Before running depreciation or performing adjustments, you must provide the necessary information in the Depreciation Override window or the FA_DEPRN_OVERRIDE table. Indicate whether the override is for depreciation or adjustments. When running depreciation, the system will upload and use the depreciation amounts provided in the interface table. You have to set the profile option FA: Enable Depreciation Override to Yes in order to use this feature.

Here is how to enter a depreciation override amounts using the Depreciation Override window:

1. As Fixed Assets Manager, navigate to Depreciation > Override.

2. In the Find Assets window, you can search for assets for which you need to change depreciation. If you did not use the Find Assets window, enter the asset number, book, and period of the asset in the rows of Depreciation Override window.

3. In Depreciation Override window, enter the override depreciation amount in the Depreciation field, or enter the override bonus depreciation amount the Bonus Depreciation field.

4. Select the adjustment type of Depreciation or Adjustment in the Use By field. The Status field displays the current status of the override record, which may be New, Post, or Posted. Set the status to ‘Post’ to submit your override. If the status is Post or Posted, you cannot update the record, you can only delete the record and reenter the updated record.

5. Save your work.

6. Run What-If Analysis or Projection to review the estimated depreciation amounts for that period. The depreciation run will pick and process your overrides in the ‘Post’ status and will change them to the ‘Posted’ status.

How to Reclass Projects and Tasks En Masse

December 20, 2006 on 9:20 pm | by Marian Crkon | In Feature of the Week, How To Guides | 1 Comment |  Print |  Email

Darn it. You manually set up your projects and you found out some attributes were configured incorrectly. Now what? There is good news. You can use the Project Administration feature (Oracle Projects 11i) to update Project and Task Organizations in one, easy update.

The way it works is that you create an ‘update batch’ of changes you want to apply. As Project Billing Super User [or Costing Super User], navigate to Project Administration > Mass Update Batches and generate a mass update batch:

• Enter a Batch Name, Description, and Effective Date for the batch.
• In the Generate Detail Lines region of the window, enter the selection criteria to select the projects and tasks you want to update.
• Choose Generate Detail Lines to generate the mass update batch lines.
• Review and/or revise the mass update batch by choosing Details.
• When ready to execute the mass update, Submit the batch. The system submits a concurrent request, which completes the update.

The system will also update all related burdening and cross-charge schedules and take the new organizations into account after the change.

Enhancement Tip

Unfortunately, the Mass Update functionality is only available to update Project and Task Organizations at this point (11i). It would be great if additional attributes were available, including Start Date and Completion Date, Key Members, Project Classifications, Service Type, etc. Judging by the fact that the ‘Attribute’ field has a drop-down menu, that was probably an original intention, but it was never implemented.

Also, the batch control functions are currently not arranged in any logical order and were confusing to the users. Arranging the functions left-to-right, or right-to-left according to follow their logical work flow would make more sense.

Foresee Those Future-Dated Expense Report Items

November 14, 2006 on 10:18 am | by Marian Crkon | In Feature of the Week | 6 Comments |  Print |  Email

You can encounter this feature when using Oracle iExpenses, Payables and Projects 11i.10.

The Feature

Oracle iExpenses 11i.10 lets you enter, approve and pay expense report items with incorrect dates in the future. I was asked by my client today to look into expense report items rejected in the Payables to Projects interface and to my surprise, there were several project-related items in Payables with item dates in the future. The item date is entered by employees when entering their expense report line items. I believe the dates were in most, if not all cases entered in error [and against the expense reimbursement policy].

The Interface Expense Reports from Payables to Projects process checks for, among other things, the following conditions:

• Expenditure Item Date is within an active employee assignment

• Expenditure Item Date is within an active project (and task) date range

• Expenditure Item Date is within an open or future PA Period in Projects

• Expenditure Item is charged to a project in an active status.

Now, this validation happens online during expense report entry and approval, but it happens again several days, or weeks, later during the Payables to Projects interface process. This is after the expense report had already been entered, approved, imported into Payables, validated and accounted for in Payables, and in many cases, already paid, and after some of the original conditions may have changed. Since these are the invoice line item dates, not invoice dates, it is very difficult for Expense Reports Auditors, or Payables, to catch these. Furthermore, once invoices are validated and accounted for, they cannot be updated.

The Workaround

As of OIE.H or higher, you can use the Future-dated expenses feature. You can use the setup utility to define whether future-dated expenses should be treated as warnings or errors during expenses entry. This ensures that expenses are not entered into inappropriate accounting periods, which causes reimbursements billing to be delayed and accounting to be incorrect.

To set the future-dated tolerances, log in with Internet Expenses Setup and Administration responsibility > Expenses Setup > General > Options. On this page you can define future-date tolerances for each operating unit. Individuals can submit future-dated expenses according to the values you specify.

If you did not set these tolerance limits and want to see whether any future-dated items exist in your system, use the ad-hoc query below.

Future-Dated Expense Report Items

Automatic Timecard Approval for Terminated Employees

July 18, 2006 on 8:18 pm | by Marian Crkon | In Feature of the Week | Enter Comments |  Print |  Email

You may encounter this feature if using Oracle Time and Labor and Oracle Projects 11i.10.

The Feature

Employees enter their project-related timecards in OTL and you want to import them to Oracle Projects. If the timecards are automatically approved by the Workflow Background Process (OTL Workflows for Employees item), they will not get approved for terminated employees and contingent workers. It appears the date of the approval process must fall within the person’s period of employment or placement to complete successfully. If the approval process is outside of the period of employment/placement the approval process fails with the error message ‘ORA-20001: This person does not have preferences for the selected effective date’, which generates an email to the System Administrator.

The Metalink Note 338716.1 describes a similar issue. In the note, Oracle recommends disabling the deferred approval option and approving timecards instantly upon their submission. This would not work because it leaves users with no option to withdraw and correct their timecards once they were submitted.

The Workaround

You need to reverse the terminations for the people on the unapproved timecards list and use the $FND_TOP/sql/wfretry.sql script to approve their timecards. Then run the PRC: Transaction Import Process in Projects to interface the timecards to Projects. And last but not least re-enter the employee terminations.

Another way to avoid this situation is to implement timecard approval by supervisor or project manager. However for those who do require this kind of approval and want to approve timecards automatically, it would be very helpful if the Workflow Background Process had a date parameter, so that it would be possible to run the approval process for past dates.

Using Expense Cost Center in Project Expense Report Account Generator

June 5, 2006 on 9:02 pm | by Marian Crkon | In Feature of the Week | 3 Comments |  Print |  Email

The Feature

You may encounter this feature if using Oracle iExpenses, Payables and Projects 11i.10. When creating project-related expense reports (invoice type = Expense Report) directly in Payables, Oracle uses the same Project Expense Report Account Generator process as used by iExpenses.

You might have a problem with populating the Cost Center segment during account generation if you use the Expense Cost Center attribute (Override Cost Center field from the expense report header) in your account generator definition. When expense reports are created or adjusted directly in Payables, the Expense Cost Center is not a valid source attribute in Account Generator, and account generation fails.

The Workaround

When creating expense report distribution lines in Payables, bypass the use of Account Generator by populating the GL Account fields first, saving your changes, and only then populating the project related attributes (project, task expenditure type and expenditure date).

How Account Generation Really Works in Oracle iExpenses

March 10, 2006 on 9:43 am | by Marian Crkon | In Feature of the Week, How To Guides | 4 Comments |  Print |  Email

Speaking about features and idiosyncrasies, let’s talk about how the accounting flexfield is generated in Oracle iExpenses (10.5.10) when employee submits his or her expense report. For simplicity sake, let’s assume the expense report does not have any multi-currency or credit card items. And as example, let’s assume we are using a simple chart of accounts containing of three segments:

Company-Cost Center-Account

Our employee belongs to company 100, and cost center 1000. Oracle iExpenses follows these steps to generate his account during the expense report entry:

Step 1: The Default Expense Account Defined in employee’s HR assignment:

100-1000-55555

Step 2: Employee enters the Expense Report Header. If he does not override the Cost Center, iExpenses proceeds to Step 3. If he does override the Cost Center (e.g. 2000), Oracle iExpenses builds an initial accounting combination of his Default Expense Account with his new Override Department.

100-2000-55555

The Feature: If this initial combination is invalid, employee will be able to proceed with the expense report entry but the report submission will fail without notifying the employee and regardless what the employee enters below!

Step 3: Employee enters expense line with an expense type (e.g. Airfare=50050) and no project. The system generates the expense line accounting flexfield. If project and task are entered, the system proceeds to Step 5:

100-2000-50050

Step 4: If Expense Allocations functionality is enabled, employee can change the above expense distribution for each line (e.g. 200-2222). If the above expense combination is invalid and the employee does not update it, the expense report submission will fail.

200-2222-50050

Step 5: Project and Task were entered at the expense line level: iExpenses will engage the Account Generator, and will follow its rules to update the initial combination, and build the new one. For example, let’s say the Company is derived from Project Organization (Seattle=100), Department from Override Department above (2000), and Account from Expense Type (Airfare). The resulting accounting combination will look as follows:

200-2000-50050

Implementation Tip: Define one Default Expense Account to be valid across all combinations of companies and cost centers, which will be used in cross-charges.

Hope you will find this information helpful. We did not have much luck trying to figure this out using the available Oracle resources.

Provide comments, or contact me at marian.crkon@itsafeature.com if you have any questions.

Little Loved Lookup Set Maintenance

March 7, 2006 on 10:27 pm | by Marian Crkon | In Feature of the Week | Enter Comments |  Print |  Email

You may encounter this feature if using Oracle Projects 10.5.10.

The Feature

Maintaining Lookup Sets. I understand their role as user-definable mapping tables between the project attributes and the chart of accounts values. They are great for mapping anything you want – legacy values to Oracle chart of accounts, third party applications to Oracle Projects, etc.

Typically, you end up maintainig same pairings of attributes – HR organization to GL companies, HR organizations to GL cost centers, expenditure types to GL accounts, event types to GL accounts etc. However, having the mapping based on values without any validation creates a maintenance nightmare. Imagine a business with several hundred to several thousands departments. In order to meet the business needs, you define several lookups sets, which map HR organizations to GL company, division or department values, etc. Imagine you change departments names in HR several times a year. Keeping lookup sets up-to-date is a full time job! There is no API, no WebADI upload, no mass update, only a good old Update Lookup Set DataLoad to make the maintenance easier.

Enhancement Tip

Why not build parameters into lookup sets, similar to AutoAccounting Rule parameters? Based on lookup values “parameters”, or “types”, you could store lookup values based on their internal IDs, not actual values. That way, if for instance HR department names change in HR, so will their corresponding lookup values in the lookup sets in Projects. There could be “Text Only” lookup sets too for mapping values, which do not originate in Oracle.

How High Can You Get?

March 2, 2006 on 12:29 pm | by Garet Keller | In Feature of the Week | 2 Comments |  Print |  Email

Unlike Donkey Kong where the longer you play the faster it gets, with Oracle Applications, the longer you play the slower it gets. Just ask an APPS DBA or anybody that was part of an upgrade from 10.7 to 11i.

What is a terabyte? In the world of Oracle Applications 11i it’s a lot of data and this data needs to be accessible to the user’s real time or the heavy hand of Audit and Sarbanes Oxley will strike you down “ GAME OVER. As Oracle continues to enhance its product with additional modules and “features” within a module (Example the AP AE_ACCOUNTING LINES with 11i) the tables grow and grow. IT tech folks have had few options, add disk, buy bigger servers, switch to RAC etc. Beyond the Production instance we all need QA, DEV and Support instances that grow the Prod terabyte exponentially.

There is a solution for this, it’s called ARCHIVE. Many of us functional analysts have looked at the Oracle purge routines and they are enticing (when they work) but try selling them to your business customers. It just won’t happen, the business customers don’t want to fish through an XML flat file to find audit data and I don’t either. Archiving allows the data to be moved from the production tables and placed on a history instance that can be viewed using data groups and responsibilities using your Production instance. This allows the production tables to be re-sized and reorganized for better performance and the data is still accessible to the business customers on-line on production.

There are a few companies that provide tools to do this and each has their pros and cons. I’ve worked with Applimation’s Informia Archive solution and I really liked it. The tool is easy to use and the code easy to view and modify if needed. The code is based on Oracle’s Standard purge routine.

For more information, look up the tool on this website www.applimation.com or you can reach out to me at garet@connectconsultingllc.com.

GL Date in Expenditure Inquiry is Misleading

March 2, 2006 on 10:40 am | by Marian Crkon | In Feature of the Week | Enter Comments |  Print |  Email

Using the GL Date for reporting and online inquiries in Oracle Projects may be misleading. Oracle Projects generates additional distribution lines to account for any expenditure adjustments, and it assigns the GL Date from based on the current open GL period from the latest distribution line. If you adjusted expenditure items within the same project and task, Oracle Projects only creates reversing distribution line, and no reversing expenditure item.

In the example below, a January timecard line was adjusted in February (with January already closed), and even though the accounting total in February was net zero, the timecard line now shows up in February using the GL Date. If you use GL Date in your reports, this item now shows up in February.

You should use the Expenditure Item Date for utilization reporting and billing in Projects because that’s when the work actually occurred. Use the distribution lines totals, not the expenditure items totals if you use the GL Date in your financial reporting from Projects.

Provide your comments, or contact me at marian.crkon@itsafeature.com if you have any questions.

I Wish There Was a Date Parameter in Transaction Import

March 1, 2006 on 6:24 pm | by Marian Crkon | In Feature of the Week | 1 Comment |  Print |  Email

I wish there was a date parameter in the Workflow Background Process and the Oracle Projects Transaction Import process. You may encounter this feature if using Oracle Time and Labor with Oracle Project Costing (10.5.10).

The Feature

Employees enter project-related timecards in Oracle Time and Labor (OTL). The timecards can be approved either automatically by the system (Workflow Background Process), or according to the approval method defined in OTL. Once the timecards are approved, a Projects Time Auditor can import them into Oracle Projects using the Transaction Import process.

Neither the Workflow Background Process, or the Transaction Import, has a date parameter. As a result, all eligible timecards get approved and imported, including future-dated ones. In some cases, timecards may be entered incorrectly into future periods. If those periods are still closed in Projects, it causes rejections during the labor distribution (costing) process. And since most clients do not allow changes to approved timecards, they are impossible to correct.

As I said, I wish there was a Date-Through parameter in the Transaction Import process.