In my last posting we discussed the various options for cross charging within Oracle Projects.  Today I would like to focus on the options of Inter-Project Billing and Inter-Company Billing and the issues with utilizing either one.

As stated in my last blog, the cross charging options were broken down as follows

As you can see from the chart above the only way to cross ledgers (utilizing standard functionality) in R12 is with either Inter-Project Billing or Intercompany Billing.  Both of which were defined as follows:

Inter-Project Billing – Unlike Direct Charge and Borrowed and Lent functionality, this functionality will require the setup and maintenance of multiple projects. This method requires that the Provider/Receiver controls have the Cross Charge Process Method of None.  In this model one project will bill the customer while multiple other projects charge into it.  This method will support charging across ledgers.  In addition, this method also allows for multiple “Receiver” projects in the receiving OU.  In addition, this functionality will result in the generation of internal AR/AP invoices.  The providing projects will generate internal AR invoices that will result in internal AP invoices for the receiving project.  Therefore, this functionality will require that Provider OU’s be setup as suppliers and Receiver OU’s be setup as customers.  A key advantage to Inter-Project Billing is that even though costs are initially collected across different projects they are captured in the project that is billing the customer.  Additionally, the associated AP Invoice for the Receiving OU is created automatically via the PRC: Tieback Invoices from Receivables process that is run in the Provider OU.  These invoices will be imported into AP via the Open Invoice Interface.  The Supplier Invoice Account Generator will have to be modified to properly account for internal AP invoices.  In addition, the AutoAccounting in Projects will need to be configured as well to generate the appropriate accounting.  This option will support cross charging across ledgers.

Intercompany Billing – This functionality works the same as the Inter-Project Billing functionality with one key exception, there can only be one receiving project per organization.  In this case Provider OU’s will bill the Receiver OU’s Intercompany Billing project only.  In addition, the Provider/Receiver controls must have the Cross Charge Process method set to Intercompany Billing.  The project in the Receiver OU that is responsible for billing the customer will NOT have the costs from the various other projects that supported it as these costs are billed to the OU level Receiving Project.  In addition, you will need to configure the Intercompany Revenue and Intercompany Invoicing AutoAccounting functions.  The Supplier Invoice Account Generator will also have to be modified to properly account for internal AP invoices.  This option will support cross charging across ledgers.

So to keep it simple, Inter-Project Billing supports the utilization of multiple receiver projects; whereas Intercompany only allows for one receiver project at the operating unit level.   Another point to consider is that Intercompany Billing CANNOT be utilized with Capital Projects.  You must use Inter-Project Billing when utilizing Capital Projects.  As you can well imagine the requirement to utilize receiver projects no matter what model you choose will increase the number of projects that you will have to create and maintain.  If you are utilizing Inter-Project Billing the number of projects and the associated overhead could increase dramatically.

I have had a number of customers tell me they really don’t want to have to deal with the additional overhead related to creating and maintaining the additional projects to support Inter-Project Billing and want a way to maintain the accounting functionality that is delivered as a result of utilizing this functionality.

At a recent client we ran into this very scenario.  The client is a multiple OU/Ledger company that consistently has OU’s charging one another to support their Contract and Internal Projects (Non-Capital).

The solution we developed was to leverage standard cross charge functionality to allow the external OU’s to charge directly to the project.  Because we had controls in place that allowed only certain companies to charge to certain ledgers we had to configure AutoAccounting to address the situation.  The appropriate cost rules were modified to determine if the company charging the project was in the OU that owned the project and depending on the result of the comparison the company segment was then populated with a value that was acceptable to the Ledger being processed.  In addition, the Account segment rule had to be modified to utilize the same comparison to determine if the transaction should book to intercompany or expense.  If the result of the comparison determined the company charging the project was not within the OU of the company that owned the project then the charge is booked to an intercompany account.  This solution worked fine for building out the entries for the ledger being processed but we still needed to address the ledger that owned the project.

In order to generate the appropriate entries to offset the intercompany transactions we had to design a custom program in GL.  Basically the program locates the intercompany transactions that were posted to GL.  From this population of transactions the program builds the appropriate offsetting entries to the appropriate ledgers and loads them to GL via the Journal load functionality, this giving us the capability to cross ledgers with the proper accounting entries in the appropriate ledgers without invoking Inter-Project Billing and incurring the associated overhead.

To illustrate the solution:

Project A is in the UK Operating Unit with a Project Currency of GBP (assume conversion rate of 1.5).

Company Segment for US OU = 10

Company Segment for UK OU = 61

Intercompany Account = 11111

Expense Account = 33333

Labor Clearing Account = 22222

The US Operating Unit is providing resources to support this project.  Based upon the Provider/Receiver Controls setups the US Operating Unit can charge directly to the UK Operating Unit.

An US employee charges $100 worth of labor cost to the UK via OTL.  Because the cost for the labor transactions must be processed in the OU in which the resource resides, the PRC: Distribute Labor Costs Process must be run in the US OU in order to properly account the transaction.  Based upon the fact the transaction is from an OU outside of the OU that owns the projects the process returns the following results.

After the transactions has been posted to GL, the custom concurrent program for building the off-setting entries for the UK OU can be fired and will return the following results.

As you can see the proper accounting entries can be generated with the proper amounts reflected at the proper currency valuations with this approach – across ledgers and without implementing Inter-Project or Intercompany Billing.

Note this approach may not work in all instances and is definitely contingent upon your application footprint.  It is also important to note that this model will only work for Contract and Indirect projects.  It does not support Capital Projects and as stated previously the only model that will support Capital Projects is Inter-Project Billing.

Over the past several implementations we have dealt with we have encountered more than a few variations as to how customers want to handle their cross charge transactions.  And as you can well imagine this always leads to numerous questions as to how the functionality works and what exactly the options are.  It is often difficult as an implementer to get across to the client just what the best fit is because they often aren’t sure of what their future structure could look like post implementation.  It’s kind of like dealing with the infamous word problem from elementary school and realizing you may not have enough information to solve the problem and the last train to Clarksville might get there without you.

Basically there are some key questions you will need to take into consideration when addressing cross charging within Oracle Projects.  First thing you will need to determine is are there separate ledgers involved.  If there are then your options are going to be limited.  But before we get into that let’s discuss all of the options first.

Per the Oracle documentation there are three TYPES of cross charging transactions (see below) which use either Borrowed and Lent, Intercompany Billing or No Cross Charge Process as METHODS of cross charging.

Cross Charge Processing Methods

You can choose one of the following processing methods for cross charge transactions.

• Borrowed and Lent Accounting (inter-operating unit and intra-operating unit cross charges)
• Intercompany Billing Accounting (intercompany and inter-operating unit cross charges)
• No Cross Charge Process (intercompany, inter-operating unit, and intra-operating unit cross charges)

The Borrowed and Lent method allows you to cross charge between organizations (intra-operating unit) or between operating units (inter-operating unit).  You can only charge between operating units if the legal entities (ledgers) are the same, which they typically are not.  This method creates accounting entries to pass costs and revenue without generating internal invoices.  Transfer pricing can be defined for this method.

The Intercompany method allows you to cross charge between legal entities (intercompany) or between operating units (inter-operating unit).  This method is typically chosen when companies are required to generate internal invoices due to legal and/or statutory requirements.

The No Cross Charge Method is used if there is not a requirement to process the cross charge transactions, but there is still a requirement to reflect charges or revenue from one project to another project.

Direct Charge – This functionality basically supports charges across Operating Units (OU) by implementing the proper Provider/Receiver controls (set Cross Charge Process Method to None)  users can book time and or other charges directly to a project in a different OU than they reside in.  This option would not use Transfer Price rules to process cost/revenue relief.  The AutoAccounting setups would have to be configured to properly account the transactions to support the client’s business rules.  In addition, this option will not support charging across ledgers.

Borrowed and Lent – This functionality works exactly like the standard Direct Charge with the exception that it uses Transfer Price Rules to address cost relief/revenue award for the providing organization.  In addition the Provider/Receiver controls would need to be set to have a Cross Charge Process Method of Borrowed and Lent.  You will have to setup AutoAccounting Functions for Borrowed and Lent processing for this functionality. This option will not support charging across ledgers.

Inter-Project Billing – Unlike Direct Charge and Borrowed and Lent functionality, this functionality will require the setup and maintenance of multiple projects. This method requires that the Provider/Receiver controls have the Cross Charge Process Method of None.  In this model one project will bill the customer while multiple other projects charge into it.  This method will support charging across ledgers.  In addition, this method also allows for multiple “Receiver” projects in the receiving OU.  In addition, this functionality will result in the generation of internal AR/AP invoices.  The providing projects will generate internal AR invoices that will result in internal AP invoices for the receiving project.  Therefore, this functionality will require that Provider OU’s be setup as suppliers and Receiver OU’s be setup as customers.  A key advantage to Inter-Project Billing is that even though costs are initially collected across different projects they are captured in the project that is billing the customer.  Additionally, the associated AP Invoice for the Receiving OU is created automatically via the PRC: Tieback Invoices from Receivables process that is run in the Provider OU.  These invoices will be imported into AP via the Open Invoice Interface.  The Supplier Invoice Account Generator will have to be modified to properly account for internal AP invoices.  In addition, the AutoAccounting in Projects will need to be configured as well to generate the appropriate accounting.  This option will support cross charging across ledgers.

Intercompany Billing – This functionality works the same as the Inter-Project Billing functionality with one key exception, there can only be one receiving project per organization.  In this case Provider OU’s will bill the Receiver OU’s Intercompany Billing project only.  In addition, the Provider/Receiver controls must have the Cross Charge Process method set to Intercompany Billing.  The project in the Receiver OU that is responsible for billing the customer will NOT have the costs from the various other projects that supported it as these costs are billed to the OU level Receiving Project.  In addition, you will need to configure the Intercompany Revenue and Intercompany Invoicing AutoAccounting functions.  The Supplier Invoice Account Generator will also have to be modified to properly account for internal AP invoices.  This option will support cross charging across ledgers.

So as a guide to get you there; think of cross charging in terms of the following matrix, which will provide you with a rule of thumb approach for making your decision.

Our next installment will deal with performing Cross Charging with a non-standard process.

With the advent of Oracle Project Management we were introduced to the concept of the User Defined Attribute (UDA) as an alternative to the standard Descriptive FlexField (DFF).  However, I’ve had many clients that were unaware of the advantages of using UDA’s rather than DFF’s.

In the past the DFF has been the goto item for storing custom data that is entered by a user to support custom processes and reports.  While powerful , one of the major disadvantages is that a developer would have to build their code around reaching to different tables or creating a custom view to make the coding more efficient when writing code for extensions, custom processes, and reports.  In addition, there are only a limited number of DFF’s available.

By utilizing the UDA functionality implementers can allow the user community to enter custom information in Oracle Project Management to drive any type of extensions, custom processes or report.   Basically the UDA’s can be assigned at a Project or Task level.  The UDA can be assigned via a context of Project Classification, Project Type, Task Type, or Project Class Code.  A custom page is created automatically during this process with no development required to support data entry.  Another key advantage of this functionality is that there is an option to automatically create a custom database view based upon the UDA information.  This greatly enhances your abilities to support extended functionality as it potentially reduces the amount of development required by a developer to deliver a solution while providing an unlimited number of UDA’s in which to store data.

In the past we have implemented this functionality to support the following:

• Project Role Based Budgeting
• Composite Rate Budgeting/Forecasting
• Equipment Run Time Hours Reporting

Below is an example of the UDA form that was utilized for Project Role Based Budgeting.

While the DFF is still an option for storing custom data, you can see the UDA functionality offers a solid solution for driving extended functionality within Oracle Projects.

Well, Open World 2012 is officially in the books and although it was exhausting, it has been exciting.  As I stated in my last blog, there has been no official release date for Oracle 12.2.  However, there are some exciting developments coming in the near future.

From the OAUG Engineering and Construction SIG we learned of three new functionality features that will be coming in the future – two of which will be in the next 12 months as targeted by Oracle.

Due in the next 12 months:

• Project Driven Supply Chain Integration – this functionality will allow Project Managers and Team Members to be able to control the purchasing the purchasing process within Oracle Projects by utilizing the following
  • Task Dates can be utilized to drive Need By Dates in Procurement
  • Negotiated Pricing can be taken into account when making purchases and can be incorporated into the planning/budgeting process.
  • Project Managers and Team Members can drive Purchase Requisitions from Projects to initiate the Purchasing Process for the Buyer.
  • Project based criteria can be utilized to help the buyer make decisions in regard to which vendors to purchase goods from.
• Financial Plan Based Project Controls – this functionality will allow for Progress to be applied directly to the Financial Plans rather than forcing customers to utilize Workplan functionality.
  • Project Managers and Team Members will be able to apply progress to project Financial Plans to enable more efficient Forecast generation for those customers who do not implement the Workplan functionality.

Functionality due beyond 12 months:

• Streamlined Billing and Revenue – this functionality will introduce the concept of Progress Based Billing.  This method is utilized by many engineering and construction companies and is the standard per the American Institute of Architects (AIA).  Project Managers and Team Members will be able to record the following to determine invoicing amounts
  • Applications for Payment
  • Progress Certifications
  • Earned Value Amounts

An item to note on this is that Perficient has a solution developed to address this form of Project Billing.  Please use the link below to access our data sheet for this offering.

Perficient Progress Billing Solution

Well, day one is officially in the books for Open World 2012 and it has been exciting.  For those of you who were in town on Sunday to attend the various special interest group (SIG) conferences it is obviously day two.  Either way there have been some informative sessions presented by the various presenters at this year’s conference and I would like to share some of that information with you.

First of all, there has been no official release date for Oracle 12.2.  However, there are some exciting developments coming in the near future.

From the OAUG Projects SIG we learned that Self-Assessed Tax functionality is now available for Oracle Projects.  The transactions will be posted to Oracle Projects via the standard AP interface.  The configuration for Self-Assessed Tax will be done in eB Tax.

In addition, we also learned that you will now be able to plan at a single planning resource level in Projects 12.2.  This functionality will allow organizations to plan their projects at a higher level than the standard resource classes of People, Financial Elements, Equipment, and Material, thus, making the planning process much more efficient for these organizations.  In addition, the resource budget vs. actual reporting is now more accurate for these companies as well.

Probably the most exciting item was the unveiling of the new Endeca product.  Endeca is a new user interface for Oracle’s Applications.  At present, Endeca is available for some of the Oracle applications on release 12.1.3 – and one of these is Project Management.  Endeca provides the capability for users to search for data in unguided and guided navigation modes.  Think of the search capabilities you have on Amazon and you get the picture.  The functionality allows Project Managers to review common sets of data and perform updates and actions on multiple tasks at a time.  Thereby, eliminating the need to drill through multiple clicks to arrive at the point to which an action needs to be performed.  Endeca provides a dashboard approach to the project list page with associated metrics to give project team members the information they need in order to react and make decisions immediately.  If you are in town stop by the Oracle Demo Grounds booth W-121 to see a demo of the Endeca tool.

More to come…..

I remember several years ago (too many to mention) in one of my former careers (once again too many to mention) at a marine construction facility, we had to bring in a large number of contingent workers to supplement our workforce in order to meet project deadlines.  As you can well imagine this introduced the same issues anyone else has faced when contingent workers are employed – chasing timesheets, reconciling vendor invoices with hours booked to the project, dealing with vendor questions in regard to payments, and many others that are too numerous to mention.  I can remember many a day thinking there’s got to be a better way.  Good News!  There is.

The Contingent Worker functionality available from Oracle allows you the ability to setup contingent workers as sub-contract employees in the HR system.  Thus, allowing them to enter time in OTL.  The integration with Oracle Projects allows these transactions to be interfaced as labor transactions rather than supplier invoice transactions.  In addition, you may also implement additional AutoAccounting rules to derive further detailed accounting for these transactions.  PO/AP integration allows for the automatic generation of receipts based upon approved timecards and additionally, allows for the automatic creation of supplier invoices.

As far back as Family Pack M for Oracle Projects Contingent Worker functionality has been in place.  And with the current release Oracle has made the functionality more robust, however, there still seems to be quite a number of basic questions as to how the functionality works and that’s what we’ll focus on today.

What are the advantages of implementing the Contingent Worker functionality? – There are several advantages to implementing this functionality

• Invoice Reconciliation
  • By implementing Electronic Receipt Settlement (ERS) for your contingent worker vendors you can eliminate the tedious effort of reconciling vendor invoices to hours recorded to a project.  With ERS vendor invoices are automatically created based upon the approved timesheets for their contingent workers
• Project Billing
  • By interfacing the contingent worker transactions as labor transactions to Projects, contingent workers can be billed the same as employees, thus eliminating any issues with converting vendor dollars to labor hours.
• Project Performance
  • With contingent worker transactions processed as labor you will gain the benefits of being able to track all labor hours on the project against budget.  This will aid in the development of more accurate forecasts.
  • In addition, you will also be able to maintain a historical record of all labor charges for future bids and proposals.

Do we have to implement Accrue on Receipt functionality for the Contingent Worker functionality to work? – In a word, no.  The only thing that needs to be done is to make sure the matching level is set to three-way and the supplier is Pay on Receipt for the purchase order for the services.

What are the options for controlling the transactions and accounting for Contingent Worker transactions? – On the Costing tab of the System Implementation Options form you can select whether or not you want to import Contingent Worker transactions. This option will determine whether or not the costs are viewed in projects as labor transactions or as supplier invoice transactions.  In addition, you can also select whether or not you want to interface the Contingent Worker transactions from Projects to GL.  If this option is checked you will need to take into consideration the fact that the accounting lines from AP will post to GL and you do not want to double post the transactions.  As an example, your accounting from AP would look like the following:

• DR = Expense
• CR = AP Liability

While the accounting from Projects for the Contingent Worker labor could look something like this:

• DR = Job Cost
• CR = Expense (Same as account above)

Are remaining Purchase Order balances stored as Commitments? – As a matter of fact they are and depending upon your method of importing the costs to projects the commitments are relieved.

What types of adjustments are available in for Contingent Worker transactions? – The standard adjustments in Oracle Projects (Transfers, Splits, etc.) are available to use as with standard labor transactions.  In addition, options can be set in OTL to allow for the timecards to be adjusted even though it has already been approved.