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 work force, allowing resources to go across all the above-mentioned boundaries 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 all of these boundaries to effectively 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:
Oracle Projects, enables you to go across all of these boundaries to enable 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. In order to enable global organizations, you need to have visibility across BGs and hence need to enable C(ross) B(usiness) G(roup) A(ccess) mode. CBGA is enabled via a profile option at the site level along with setup of global organization hierarchies and security profiles that permit access to organizations across business groups linked to responsibilities. There is an additional feature called global job groups that may be mapped to BG specific job groups in order 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 or both meaning that projects are owned by one set of organizations and project resources by another set or that projects and project resources are owned by the same organizations. This is purely dependent on how the business is organized to operate.
Cross-Charging and Cross-Charge Processing
For the purposes of determining 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 and 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
- 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 is 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)
- Borrowed and Lent Accounting
- Inter-Operating Unit (within the Same Legal Entity)
- Borrowed and Lent Accounting OR
- Intercompany Invoicing
- Inter-Legal Entity
- Intercompany Invoicing
The next step in the process is to determine what the amount to be processed will be. This amount represents the reimbursement to be sent to the provider organization for work done for on a project for the receiving organization. This amount is also termed as the “Transfer Price”. The transfer price may be classified as cost or revenue representing if the providing organization is sharing it’s cost with the receiver or receiving a share of the revenue from the receiver. Transfer price is determined by a transfer price schedule that specified 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.
This is the next major requirement to support global project centric organizations. Handling multiple currencies is a complex piece of 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 project) and Project Functional (accounting) Currencies
Agreement: Agreement Currency in addition to the base project currencies.
Funding: Is always in Agreement Currency in addition to the base project currencies.
Budgeting/Forecasting: plan lines can be enabled to be in any currency and are automatically converted to the base project currencies. 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 (san 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 project, project functional or funding currency).
With funding in foreign currencies, there is always the challenge of fluctuating funding amounts based on currency fluctuations. In order to handle this, Oracle Projects has a function called funding revaluation. This process handles two different pieces of 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 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 to local language (Headings, Prompts, etc) – Forms, Reports, Messages, HTML Screens
- Projects is fully compliant with this
- MLS: Multi-Lingual Support
- All key data elements are translatable
- Seed Data, Setup Data, Key Entities (like Project, Task)
- Projects is partially compliant with this – Not all setup entities are MLS enabled. For example, 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 in order to enable effective communication is global projects and hence any initiative for handling multiple languages can include NLS but MLS must be handled with a lot of thought.
Oracle Projects provides 4 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.