The Feature

How To Capitalize Legacy CIP Costs in Oracle Projects

August 10, 2010 on 8:55 pm | by Marian Crkon | In How To Guides, Ideas and Opinions | Enter Comments |  Print |  Email

Here is a quick summary of steps to convert legacy CIP costs on capital projects and capitalize them into assets. The instructions are applicable to both: Oracle EBS 11i and R12. This article assumes that you have already configured all prerequisites in your Oracle Project Costing and Fixed Assets. You will need Project Costing Super User and Fixed Assets Manager responsibilities, or the customized versions there of.

Define Capital Projects

Let’s start with defining the project template. This is where you can leverage a lot of good Oracle functionality to your benefit.  The details will vary in every instance, but in general, you need to complete the following steps:

PA1: Define Capital Project Template – Header

Navigate to Setup > Project > Project Templates to create a new template. Define the header-level information including the Number, Name, Project Type (make sure it is a Capital  project type class – you won’t be able to change it later), Organization, and Description.  If you want project created from this template to have a fixed duration (e.g. 12 months), define the Trans Duration. The system will populate the Project Finish dates based on the Project Start date and this duration for new projects.

PA2: Define Capital Project Template – Quick Entry Fields

Click on Setup Quick Entry. Define the fields for quick entry of projects. These are the “bare minimum fields” to enter when you copy a template into a project.

PA3: Define Capital Project Template – Tasks

Click on the blue box next to the Tasks option (I know, it not very intuitive), or click on Detail (while the cursor is on Tasks). Define your tasks, or work breakdown structure (WBS). Also determine which tasks should be capitalizable or not, i.e. can collect CIP costs to become fixed assets.

PA4: Define Capital Project Template – Define Project Assets

In this step, you can pre-define fixed assets you anticipate to complete as part of projects created from this template. Basically, you do here what you’d normally do in FA Mass Additions. You can use the Create Project Assets DataLoad to upload a higher volume of assets…

PA5: Define Capital Project Template – Assign Project Assets

Depending on your implementation approach, you assign default assets at project or task level. This functionality determines how the capitalizable expenditures will be assigned to future assets. In order to automate this, you probably want to assign assets at the task level so that you have one-to-one relationship between the costs and the assets in your tasks. The other options would be the costs in multiple tasks to be summarized into one asset at the project level… Refer to the Asset Summary and Detail Grouping Options in the Oracle Project Costing User Guide. You can use the Create Task Level Asset Assignments.

PA6: Define Capital Project Template – Create Task Transaction Controls

Following the example of the task-level asset assignment we defined in step PA5 above, it is critical, that the right CIP costs get collected in the right tasks. In other words, we want building-related costs be collected in building-specific task to capitalize them into a building asset assigned to the same task. To prevent invalid entries, you can create Transaction Controls. These are, basically, conditions that determine what expenditure types or categories are allowed in what projects or tasks. Again, use this sample Create Task Transaction Controls DataLoad to prepare and execute your upload. The trick will be finding the right tasks based on their WBS level. And one note about the Transaction Controls: make sure the Control Start Date and End Date are consistent with your Task Start Date and Finish Date.

PA6: Define Capital Project Template – Set Task-Level Capitalizable Flag

This is an optional step, and this should be taken care of by your Transaction Controls. However, you can make all expense tasks non-capitalizable by setting the Capitalizable flag to null… You can use this Update Expense Task Capitalizable Flag DataLoad.

PA7: Create Projects

Using the template created in steps PA1-6, create your capital projects. The quick entry fields will vary depending on your template, but as always, you can use the Create Projects DataLoad.

PA8: Upload Legacy CIP Costs

Depending on your conversion strategy, you can use a custom conversion program, or WebADI spreadsheet to upload your legacy CIP costs. Check this article for detail on how to convert legacy costs and how to resolve a couple of “features” during the Transaction Import.

PA9: Update the Project Status Inquiry Amounts

As Project Costing Super User, run the PRC: Update Project Summary Amounts

PA10: Complete Asset Definitions

Based on your implementation strategy and business process, you might be required to complete asset definitions in Projects before asset lines can be generated and interfaced to Oracle Assets. As Project Costing Super User, navigate to Capitalization > Capital Projects. Query up your project(s), click on Assets > Asset Details. Complete the asset definitions, just like you would in the Prepare Mass Additions.

PA11: Generate Asset Lines

As Project Costing Super User, run the PRC: Generate Asset Lines for a Range of Projects process. Watch the Date In Service parameter and PA Date parameter to make sure you select the right lines to generate.

PA12: Interface Asset Lines to Assets

As Project Costing Super User, run the PRC: Interface Assets to Oracle Assets process. It will create mass additions in FA MASS ADDITIONS table.

FA13: Post Mass Additions

If you required complete asset definition in Projects, your mass additions are ready to be posted. If asset lines are incomplete, you need to complete them in Prepare Mass Additions. In any case, once ready, log in as Fixed Assets Manager and navigate to Mass Additions > Post Mass Additions to create assets.

At this point, your legacy CIP costs were capitalized into fixed assets. Obviously, this summary is  simplified; refer to the Oracle Project Costing User Guide and Oracle Assets User Guide for more details.

How to Convert Legacy Expenditure Balances to Oracle Projects

October 12, 2007 on 3:58 pm | by Marian Crkon | In How To Guides | 3 Comments |  Print |  Email

Here is another piece on converting legacy balances into Oracle Projects. To see how to convert your legacy project revenue and invoice balances, check here.

Before you start the legacy cost data conversion process, your Oracle Financials and Projects modules need to be fully configured and your prerequisites created. When migrating from your legacy system to Oracle Projects, you may need to bring your ending legacy balances as your opening balances in Oracle. This will allow you to seamlessly manage and report on your project activity.

For the purposes of this article, let’s take for example a scenario when you go live with Oracle Projects on January 1, 2008, and let’s assume we need to convert legacy cost balances in summary. When we extract the balances from the legacy system, we would summarize them by project, task, organization, expenditure type, and date. The balances will be created and processed as miscellaneous transactions in Oracle Projects.

Step 1 (GL): Review your chart of account values. If needed, add new values for revenue accounts, companies, departments, products, etc.

Step 2 (HR): Define your project organizations. Classify organizations that will own projects as Project/Task Owning Organizations, and classify organizations that will incur revenue as Project Expenditure/Event Organizations.

Step 3 (HR): Include new project organizations to your project organizational hierarchy.

Step 4 (HR): Create your employees and employee assignments. Each project has to have a valid employee assigned as project manager in order to generate client invoices.

Step 5 (PA): Review and update project structures: project types, project templates, expenditure categories, revenue categories, expenditure types, lookup sets…

Step 6 (PA): Create your projects and tasks. Make sure to select a correct project type for each project, i.e. (Time and Material, Fixed Price, Cost Plus, etc.) You cannot change project type once you generated project costs.

Note:

If you are converting costs from multiple years, make sure to open prior periods (e.g. DEC-06 for 2006 costs) in Projects in order to determine correct PA and GL Dates! See more details on PA and GL dates in this article. If you do not open respective prior periods, transaction GL and PA dates will be assigned in the current opened period, and your project reporting may be inaccurate.

Step 7 (PA): Define your Transaction Source. Transaction sources identify the source of external transactions you import into Oracle Projects using Transaction Import. You can define a new the transaction source ‘Conversion’ to identify your legacy costs from from your legacy system. When you create a transaction source, you control the Transaction Import processing by the options that you select. Here are few recommended settings for some key options:

• Transaction Source – Define your transaction source, e.g. ‘Conversion’.

• Default Expenditure Type Class – The system uses the default expenditure type class that you assign to a transaction source if an expenditure type class is not specified in the interface table. Enter ‘Miscellaneous Transaction’.

• Raw Cost GL Accounted – Select this option to indicate whether transactions imported from this transaction source have already been accounted for in GL. Oracle Projects expects that the external system has already posted the raw cost to the appropriate debit and credit accounts. None of the Oracle Projects processes will transfer these costs to GL or AP. If you enable tis option, you will also need to provide valid debit and credit code combination IDs. When you select this option, the Import Raw Cost Amounts option is automatically selected.

• Import Raw Cost Amounts – When a transaction source has this option enabled, the raw cost amount of the transactions has already been calculated (costed) in your external system. None of the Oracle Projects processes will calculate raw cost amounts for these transactions.

• Import Burdened Amounts – When this option is selected for a transaction source, Oracle Projects expects the external system to provide burdened costs. If the transaction does not have a burdened cost amount, Transaction Import will reject the transaction. When you select this option, the Import Raw Cost Amounts option is automatically selected.

• Allow Duplicate Reference – Enable this option to allow multiple transactions with this transaction source to use the same original system reference. If you enable this option, you cannot uniquely identify the item by transaction source and original system reference.

• Allow Interface Modifications – This option allows you to modify rejected transactions in the Review Transactions window after the import process is completed.

• Purge After Import – If you select this option, items successfully imported from the transaction source are automatically purged from the interface table when the import process is completed.

• Allow Reversals – If you enable this option, Oracle Projects allows reversals of expenditure batches or expenditure items for the transaction source. When you enable this option, the Allow Adjustments option is automatically enabled. Disable reversals for legacy balances, which should not change, i.e. balances posted in prior periods, and enable it for balances, which need to be processed as “new transactions” in Oracle Projects, e.g. unbilled billable transactions or uncapitalized capitalizable transactions.

• Allow Adjustments – If you enable this option, you can adjust imported transactions in Oracle Projects after you load them via Transaction Import. Disable adjustments for legacy balances, which should not change, i.e. balances posted in prior periods and enable it for balances, which need to be processed as “new transactions” in Oracle Projects, e.g. unbilled billable transactions or uncapitalized capitalizable transactions.

• Processing Set Size – Enter the size of the processing set. The value entered indicates the number of records to be processed in each set. When interfacing large amounts of data, you can reduce the impact of unexpected errors by processing transactions in sets. The import process issues a database commit after each set is complete. If an error occurs and a rollback is issued, only the transactions in the current set are affected.

• Effective Dates – make sure your ‘From’ effective date is before your oldest expenditure item date you intend to upload.

Step 8 (PA): Disable cost transfer to General Ledger. Navigate to the Implementation Options screen and disable the Interface Usage Costs flag. This will prevent your legacy cost balances from being interfaced to Oracle General Ledger since the assumption is they were already posted by your legacy system.

Step 9 (WebADI): Create a WebADI integrator for Project Transaction Import. You can either use one of the seeded Project Integrators, or define your own, which matches your Transaction Source.

Step 10 (PA): Upload legacy cost balances as miscellaneous expenditure transactions. For high volume uploads, create a custom script and upload your data directly into PA_TRANSACTION_INTERFACE table. For medium-size uploads of several thousands records, use the WebADI Upload spreadsheet you created in Step 9 above.

Step 11 (PA): Run Transaction Import. When using WebADI, you can submit this step during your upload. Oracle lets you fix any rejections either in your upload spreadsheet, or in the interface table using the Review Transactions form.

Note

One comment about Transaction Import Status. Even though you can correct your most of your rejections in the Review Transactions screen, Oracle Projects does not let you change transaction status from Rejected (R) to Pending (P) in the Projects Transactions Interface table. Use this Set Transaction Import Status script to re-set the status.

Step 12 (PA): Distribute transaction costs. Run the PRC: Distribute Usage and Miscellaneous Costs process to calculate the amounts and generate account distribution lines. Make sure to run this process with the right period open and the right Through Date to assign correct PA and GL dates to your legacy transactions.

Step 13 (PA): Run the interface to General Ledger. Run the PRC: Interface Usage and Miscellaneous Costs to General Ledger process. This will set the legacy cost balances to look like they are interfaced to GL. If you disabled the GL Transfer option in Step 10, no journal entries will be created. Alternatively, you can run the PRC: Submit Interface Streamline Processes with option ‘DXU: Distribute/Interface Usage and Misc. Costs to GL’ to complete steps 12 and 13 together.

Step 14 (PA): Turn back on the GL interface you disabled in Step 8. Navigate to the Implementation Options screen and enable the Interface Usage Costs flag.

And that’s it. The exact sequence of steps will, of course, depend on your company’s specific business. Hopefully, this article provided a good starting point for understanding this process.

Favorite Fusion Features – Project Costing

June 9, 2006 on 9:18 pm | by Marian Crkon | In Ideas and Opinions | Enter Comments |  Print |  Email

Which features would you like to become your Favorite Features in Oracle Fusion? If you are an expert user with real-life, hands-on experience and have ideas on how to improve the applications; if you had to customize a module to get the features you need, or additional functionality would save you time and money, submit your strategic requests via the OAUG Enhancement Request System (ERS) today! As an Oracle Applications Users Group (OAUG) member and/or Oracle Applications user, Oracle is requesting your feedback on strategic improvements to current Oracle E-Business Suite functionality for their initial Fusion releases.

Alternatively, if you want to get involved but don’t know how, if you are not an OAUG member, or none of the available options works for you, then let’s also try something different. Let’s keep a weblog of improvement tips, enhancement requests and your best features in Oracle, PeopleSoft, JD Edwards and Siebel applications you want to have in Oracle Fusion. Let’s have discussions about what enhancements and features make most sense, and then log Fusion Requests before the Oracle’s June deadline. There won’t be any wrong questions or bad ideas (or at least, we’ll let the “group intelligence” decide). Your involvement can be as easy as providing comments with your ideas to this post.
Below is a list of improvement tips and enhancement ideas based on Oracle Project Costing 11i.10 as provided by the Feature authors and readers:

• Project and Task WebADI Upload Integrator. Provide Excel integration (WebADI Integrator) for uploading projects and tasks using the existing project and task APIs.

• Project Maintenance. Maintaining projects and their options could be a drag. Yes, there are APIs to create and update projects, tasks and budgets, but in order to use them you have to create your own custom code. Many companies rely on manual project maintenance by their users. Similar to Quick Project Entry function, which is used to quickly set up projects, why not create a Quick Project Update function, which would update them? It would be great, for instance, for updating project dates, task dates and transaction controls dates when the project duration changes. You may also need to change burden schedules, price rule schedules, or any other project or task-level attributes. You get the idea…

• Expanded Project Administration. This one is similar to the one above, but it is more related to the changes to you need to make across several projects. The Project Administration functionality currently allows you to change only Project Owning Organization. It would be great to have better selection criteria like project type, customer, project manager, project classification, etc.to choose what projects need to be transferred from one organization to another. Also, it would be fantastic to be able to change additional projectattributes like Key Members, Customers, or Project Classifications using the Project Administration.

• Improved Project Allocations Rules. Project Allocations is a great feature but it could use a little more flexibility in defining rules on how to create new transactions. Being able to define only one Expenditure Organization and one Expenditure Type per rule makes it very difficult to define flexible accounting rules for allocation transactions. Having a separate AutoAccounting Function for allocations would also help.

• Validated AutoAccounting Lookup Sets. We all use them as mapping tables between project attributes and chart of accounts values. Having no validation in lookup sets gives you great flexibility to map anything you want. However, no validation also creates a maintenance nightmare. Why not build parameters into lookup sets, similar to AutoAccounting Rule parameters? You could store lookup values based on IDs, not values. That way, if or instance, HR organizations change in HR, so would their representations in the lookup sets in Projects.

• Expanded AutoAccounting Functions for Cost Clearing Accounts. The clearing account functions in AutoAccounting could use more parameters in order to create more robust and flexible rules for the cost clearing accounts. Add additional parameters like expenditure type, expenditure category, service type, project classification, etc.

• Better Error Handling for AutoAccounting Errors during Cost Processing. Many of us spend endless hours trying to figure out why costing processes fail due to “Invalid AutoAccounting” errors. Provide more detail AutoAccounting errors in the cost distribution processes.

• Expenditure Item Adjustments. Provide a way to “transfer” expenditures between Expenditure Organizations, and between Expenditure Types (similar to the existing transfer between projects and tasks). It is a major headache, especially with transactions imported into Projects (timecards, expense reports, supplier invoices) to not to be able to change these two parameters.

• Find Expenditure Types Function. It would be great to have a search function in the Expenditure Types form with Expenditure Type, Expenditure Category, Revenue Category, UOM and Expenditure Type Class as search parameters would be very helpful. Also, provide a folder/export function so that we can easily export expenditure types and their attributes. The IMP: Expenditure Type Listing is pretty useless.

• Rate Schedule Upload. Provide Excel integration (Web ADI Upload Integrator) for creating and updating Rate Schedules. It would also be nice to be able to end-date the schedules you no longer need.

Which features would you like to become your favorite features in Oracle Fusion? Granted, it may take two years before you get them, if ever, but this is your opportunity to provide your own improvement ideas and enhancement requests. The voting to determine “best features” starts in July 2006.

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.

Oracle Project Costing – Know What It Takes to Run Your Projects

February 26, 2006 on 3:00 pm | by Marian Crkon | In Reviews | 17 Comments |  Print |  Email

Oracle Project Costing is one of the core applications in Oracle Projects suite. It allows you to set up your projects, project work-breakdown structures (WBS) and project budgets, collect project-related expenditures (including timecards, expense reports, supplier invoices, inventory costs, and other miscellaneous transactions), and account for them in your General Ledger. Depending on a project type, costs can be either billable to be billed to clients, or capital (CIP) to become fixed assets, or they can be other indirect (overhead) costs associated with running your business. Oracle Projects gives you tools to process all three types.

Continue reading Oracle Project Costing – Know What It Takes to Run Your Projects…

Recompiling Burden Schedule Recalculates Existing Costs

February 22, 2006 on 7:12 pm | by Marian Crkon | In Feature of the Week | Enter Comments |  Print |  Email

You may experience this feature if you are using Project Burdening in Oracle Projects 11.5.10.

The Feature

If you updated and recompiled your burden rates in the provisional burden schedule version, or defined a new version with a retroactive start date, the system will automatically update existing transactions (typically timecards) to be re-costed. This might have a major impact on your project costing and reporting since the PA Date and GL Date for re-costed transactions will change to the current period from the period when the transactions were originally calculated.

The Workaround

While this is a great feature if used as intended, watch out if you are not familiar with it. If you do not intend to recalculate the existing burden costs with new burden rates, set the start date of the new burden schedule version to the beginning of the current period to avoid unintentional retroactive recalculation of the existing burden costs.