Implementation Profile and Key Requirements of a Global Project-Centric Organization

Global project-centric organizations using EBS have the following implementation profile:

• Multiple Legal Entities
• Multiple Business Groups
• Multiple Ledgers
• Multiple Operating Units
• Multiple Currencies
• Multiple Languages

Key requirements for operating in such an environment include contracting projects globally, executing these global projects via a geographically distributed workforce, allowing resources to go across all the boundaries mentioned above to execute projects, and the ability to receive reimbursement for work done on such projects belonging to other organizations.

Oracle Projects enables such global organizations to cross these boundaries effectively to execute global projects. The following sections show how this is accomplished.

Business Structures in EBS

Organizations are the basic building blocks of business structures in Oracle EBS. In Oracle HR, they represent the resource-owning structure. For Financials, these are modeled to be cost centers, and for projects, these are project-owning or expenditure-owning structures.

Operating Units are the financial boundaries that separate and secure transactional data. Business Groups do the same for HR data. OUs roll up into Ledgers while Legal Entity is weakly represented as an attribute of Operating Unit in HR.

These structures can be implemented in a simple manner or complex as shown by the following representations:

Simple structure:

Complex structure:

Oracle Projects enables you to go across all of these boundaries to facilitate project work in global organizations.

All HR entities are limited by  Business Group (BG), and this is linked to a responsibility allowing you access to data within the BG. This is the S(ingle) B(usiness) G(roup) A(ccess) mode. To enable global organizations, you need to have visibility across BGs and hence need to enable C(ross), B(business), G(roup) A(ccess) modes. CBGA is enabled via a profile option at the site level, along with the setup of global organization hierarchies and security profiles that permit access to organizations across business groups linked to responsibilities. Furthermore, there is an additional feature called global job groups that may be mapped to BG-specific job groups to enable needed features for global organizations, such as global rate schedules for billing and transfer pricing.

Finally, users can choose to enable organizations to be project-owning or expenditure-owning exclusively, meaning that projects are owned by one set of organizations and project resources by another or that the same organizations own projects and project resources. Again, this is purely dependent on how the business is organized to operate.

Cross-Charging and Cross-Charge Processing

To determine cross-charging, the project-owning organization and OU are termed as the “Receiver” org and OU, and the expenditure org and OU are termed as the “Provider” org and OU, respectively. Each cost transaction stores the provider and receiver org and OU independent of the project, expenditure org, and OU. These can be different if you choose to use the Oracle-provided extension to climb the hierarchy and determine cross-charging at a high level than the base project and expenditure-owning organizations.

Once the provider and receiver org and OU are known, the next step is to determine the type of cross-charge as follows:

• If Provider and Receiver OU different
  • Then If Provider and Receiver LE different
    • Inter-LE Cross Charge
  • Else Inter-OU Cross Charge
• Else if Provider and Receiver Orgs different
  • Then Intra-OU Cross Charge
  • Else No Cross Charge

Processing for cross-charged transactions can be done by accounting entries associated with Borrowed and Lent accounting or via Inter-Company Documents. The method to be used for processing cross-charged transactions is from the following options and is determined based on setup in provider-receiver controls:

• Intra-Operating Unit (Across Organizations)
  • None
  • Borrowed and Lent Accounting
• Inter-Operating Unit (within the Same Legal Entity)
  • None
  • Borrowed and Lent Accounting OR
  • Intercompany Invoicing
• Inter-Legal Entity
  • None
  • Intercompany Invoicing

The next step in the process is to determine the amount to be processed. This amount represents the reimbursement to be sent to the provider organization for work on a project for the receiving organization. This amount is also termed the “Transfer Price.” The transfer price may be classified as cost or revenue, representing if the providing organization is sharing its cost with the receiver or receiving a share of the revenue from the receiver. Transfer price is determined by a transfer price schedule that specifies a transfer prices rule to be used to determine the transfer price amount between a pair of provider-receiver organizations along with a markup or discount% and amount type (cost or revenue). The transfer price rule, in turn, determines the basis of the transfer prices as raw cost, burdened cost, or revenue and if the basis is to be used directly or to apply a burden schedule or markup/discount% to the basis.

Multi-Currency Support

This is the following major requirement to support global project-centric organizations. Handling multiple currencies is a complex function in Oracle Projects dealing with core entities for costing and billing along with the transactions for each.

Base Project: Project (single currency used to manage the project) and Project Functional (accounting) Currencies

Agreement: Agreement Currency in addition to the base project currencies.

Funding: This is always in Agreement Currency in addition to the base project currencies.

Budgeting/Forecasting: plan lines can be in any currency and automatically converted to the base project currencies. The approved revenue budget must be entered in project functional currency only and is baselined against the funding amount in the same currency.

Cost Transactions: have an expense report transaction and expenditure transaction (includes expense report reimbursement) currency in addition to the base project currencies.

Billing Transactions: Can have an Invoicing currency, a revenue currency (can be functional or invoice currency), a bill transaction currency (currency in which bill amount is computed for base billing transactions – this can be event currency, rate schedule or cost transaction currency) and bill processing currency ( common currency used to perform funds checking during billing processes – can be projected, project functional or funding currency).

With funding in foreign currencies, there is always the challenge of fluctuating funding amounts based on currency fluctuations. To handle this, Oracle Projects has a function called funding revaluation. This process handles two different pieces of the puzzle as shown below:

• Revaluating funding adjusts funding available in functional/project currency based on current exchange rates
• Creates adjustment funding lines in functional currency and baselines to the revenue budget

With invoicing in a foreign currency and receipt timing

• Two different amounts that need revaluation
• Invoice Backlog and Currency Gains/Loss from Receipts
• Each results in revenue adjustments via special events
• Enable Currency Gains/Loss only if you are holding PM responsible for managing currency fluctuations

Support for Multiple Languages

Oracle natively provides two different types of support for multiple languages as part of EBS:

• NLS: National Language Support
  • Each User Interface is Translated into the local language (Headings, Prompts, etc.) – Forms, Reports, Messages, and HTML Screens.
  • Projects are fully compliant with this
• MLS: Multi-Lingual Support
  • All essential data elements are translatable
  • Seed Data, Setup Data, Key Entities (like Project, Task)
  • Projects are partially compliant with this – Not all setup entities are MLS enabled. For example, the Expenditure Type is not MLS-enabled

The biggest challenge with multiple languages comes with global projects where resources from different language-speaking regions work on the same project. A common language is needed in these cases to enable effective communication in international projects, and hence any initiative for handling multiple languages can include NLS, but MLS must be dealt with with a lot of thought.

Global Projects

Oracle Projects provides four different models to support global projects, but that discussion is further elaborated in the paper for session #12420. In conjunction with these models and the functions described above, Oracle Projects provides comprehensive functionality to support global organizations executing project work.