Global Project Support
This chapter discusses functionality within Oracle Projects supporting operation of global enterprise, including support for multiple organizations, multiple currencies, and multiple languages.
This chapter covers the following topics:
- Providing Data Access Across Business Groups
- Defining Global Security Profiles
- Multi-Currency Support
- Converting Multiple Currencies
- Currency Models in Oracle Projects
- Reporting Currencies
- Multilingual Support
Providing Data Access Across Business Groups
Global enterprises have resources and projects that are located, managed, and accounted for in different business groups or different countries. To meet the needs of these enterprises, Oracle Projects provides the following functionality:
-
Globally located resources can charge their time and expenses to projects that are owned outside their respective business groups.
-
Resources can manage and administer projects located in different business groups.
-
Oracle Projects produces appropriate accounting entries, intercompany invoices, and management reports even if the resource organization and project owning organization have different accounting calendars and job definitions.
This functionality is provided through the use of global organization hierarchies, global jobs, and cross charge functionality.
This section covers the following topics:
Related Topics
Processing Flow for Cross Charge, Oracle Project Costing User Guide
Setting Up for Cross Charge Processing: Borrowed and Lent, Oracle Projects Implementation Guide
Setting Up for Cross Charge Processing: Intercompany Billing, Oracle Projects Implementation Guide
Shared Setup Details for Cross Charge Processing, Oracle Projects Implementation Guide
Organization Hierarchies Overview
Oracle Projects uses organization hierarchies to control project ownership, resources, and burden schedules. You control which organizations in an operating unit can own projects and tasks by associating the operating unit with a Project/Task Owning Organization Hierarchy. You define which organizations can charge expenditures to projects in an operating unit by associating the operating unit with an Expenditure Organization Hierarchy. A project can use different burden schedules for any organization belonging to the Project Burdening Hierarchy.
Global organization hierarchies are hierarchies that contain organizations from multiple business groups. By using global hierarchies, operating units can broaden their project resources beyond their own business group, using resources from other business groups to own or perform project tasks.
Related Topics
Defining Organization Hierarchies
Jobs Overview
-
to determine bill rates and transfer prices
-
to describe customer invoice lines
-
to budget and summarize project costs by resources
Organizations within your enterprise are not required to use the same job definitions. You can define job groups for specific purposes and define unique jobs for each group. You can then map a job from one group to a job in another group. For example, the job titles you need for your European operating units may be different from the job titles you need for your U.S. operating units. For global projects you can define a global job set and map your European and U.S. jobs to the appropriate global jobs. These global jobs can then be used by your global projects to provide accurate and consistent billing and reporting.
Cross Charge Functionality
Oracle Projects uses cross charge functionality to generate the appropriate accounting entries, and intercompany invoices when applicable, when the resource organization in a transaction is different from the project owning organization. For detailed information about cross charge functionality, see Overview of Cross Charge, Oracle Project Costing User Guide.
Related Topics
Business Group Access
Your site's HR Business Group Access Mode determines which organizations can belong to organization hierarchies and which jobs can be included in the job groups that are used by your operating units. Oracle HRMS provides the following two access modes:
-
Single Business Group Access (SBGA)
-
Cross Business Group Access (CBGA)
Single Business Group Access Mode
In Single Business Group Access mode, one business group encompasses all of the organizations of your company worldwide.
The following illustration shows an example of single business group access mode.
Single Business Group Access Mode
In this mode:
-
Organization hierarchies are business group specific and can contain only organizations within the business group.
-
Jobs used for bill rate calculations, invoice formats, and resource lists are limited to jobs in job groups within the business group.
-
Employees can cross charge only to projects within their business group.
Single Business Group Access Usage and Setup
Using Single Business Group Access, you log in using a user name and password. You then select a responsibility. Your user name and responsibility are linked to a business group. You can only access records for this business group. Who you can access is restricted by a security profile. Your permission to perform functions is limited by the menus assigned to your responsibility.
When using Single Business Group Access, note the following items:
-
You link one responsibility to one business group.
-
You cannot enable more than one business group for a responsibility.
-
You must define a separate responsibility for each business group.
-
Each responsibility must be assigned to one, and only one, security profile. Note that security profiles limit access to organizations within a business group.
-
The HR: Security Profile option is used to assign a security profile to a responsibility.
-
A view all security profile is automatically created for each business group. Additional security profiles are only required if you need more granular security within a business group.
-
Organization hierarchies defined in a business group can only contain organizations owned by that business group.
For detailed instructions on enabling HR Single Business Group Access, see Customizing, Reporting and System Administration in Oracle HRMS: Setting Up Standard HRMS Security.
Cross Business Group Access Mode
Use Cross Business Group Access mode when your enterprise uses more than one business group to segregate employees and organizations and you wish to allow resources to charge to projects outside their own business group.
The following illustration shows an example of cross business group access mode.
Cross Business Group Access Mode
In this mode:
-
Organization hierarchies can contain organizations from any business group.
-
Jobs used for bill rate calculations, invoice formats, and resource lists can be in any job group, without business group restrictions.
-
Employees can charge to any project in any business group within your enterprise.
HR Security Components
To understand the setup and use of business group access modes, you must understand the following HR security components.
-
Responsibilities: The responsibility is your primary means of defining security. Business groups and menu structures are linked to a responsibility.
-
Menu Structures: Using menu structures, you can limit the functions a user can access.
-
Security Profiles: Using security profiles, you can limit access to certain organizations or organization levels within a business group.
Cross Business Group Access Usage and Setup
You will benefit from using Cross Business Group Access if you have multiple business groups set up in a single database installation and you want one responsibility to be enabled for more than one business group. Using this mode, you still log in using a user name and password and select a responsibility. Your ability to perform functions is still limited by the menus assigned to your responsibility. Who you can access is still restricted by a security profile.
However, global organization hierarchies and global security profiles are not restricted to one business group. Global organization hierarchies can contain organizations from any business group. Global security profiles are created by using a global organization hierarchy to define the profile. The Assign Security Profile window is used to link the global security profile to a responsibility. Employees assigned to the global organization hierarchy are then accessible to holders of that responsibility.
When using Cross Business Group Access, note the following items:
-
You can enable more than one business group for a single responsibility.
-
You do not have to define a separate responsibility for each business group.
-
When you enable Cross Business Group Access, the system automatically creates a default global security profile that allows full access. To restrict user access, you must define additional security profiles.
-
You can define global organization hierarchies and global security profiles.
-
You use the Assign Security Profile window to assign security profiles to responsibilities.
-
The HR: Security Profile option is not used. If it is defined, it is ignored by the system.
For detailed instructions on enabling HR Cross Business Group Access, see Customizing, Reporting and System Administration in Oracle HRMS: Setting Up Cross Business Group Responsibility Security.
Important: Multiple Organization Access Control and Cross Business Group Access operate independently of each other and can be used simultaneously. Entities such as resource lists or resource breakdown structures that use business groups derive the business group from the HR: Business Group profile. Multiple Organization Access Control enables users to enter expenditure batches in several operating units without switching responsibilities.
Using Global Organization Hierarchies
If you have enabled HR Cross Business Group Access, you can define global organization hierarchies in Oracle Projects. A global organization hierarchy is a hierarchy that contains organizations from more than one business group. Global hierarchies can be used to define global security profiles to allow a responsibility access to organizations and employees across business group boundaries.
The following illustration shows an example of a global organization hierarchy.
Example Global Organization Hierarchy
In order for employees of U.K. Services to charge expenditures to projects owned by any of the U.S. operating units, a global hierarchy must be defined. The hierarchy will also allow the U.K. Services operating unit to own projects and tasks that are defined in the U.S. operating units.
Global Security Profile
Once you define the global hierarchy, you can use it to create a global security profile. Global security profiles are security profiles that are not associated with a business group. Users can view all organizations and all employees defined by the organization hierarchy assigned to the profile. See: Defining Global Security Profiles.
Assigning Global Hierarchies to Operating Units
After you define one or more global hierarchies and global security profiles, you can assign global hierarchies to each operating unit that will use global resources. This is done in the Organization Classifications region of the Organizations window.
Global hierarchies can be used as follows:
-
To expand an operating unit's default organization reporting parameter, assign a global hierarchy to the operating unit's Default Reporting Hierarchy.
-
To expand the project and task organization list of values during project setup, assign a global hierarchy to the operating unit's Project/Task Owning Hierarchy.
-
To expand which person or expenditure organization can charge expenditures in an operating unit, assign a global hierarchy to the operating unit's Expenditure Organization Hierarchy.
Note: If you use a global hierarchy for expenditures, persons, and/or non-labor resources, you must have an appropriate cost rate assigned in each operating unit used by those resources to enter their expenditures.
For more information about assigning organization hierarchies, see Organizations.
Job Groups and Global Jobs
When jobs are defined they are assigned to a job group. Multiple job groups can be defined for various purposes. For example, HRMS jobs are defined to reflect HR characteristics and may be different from project jobs. Therefore, you can define an HR job group and a Projects job group. Also, job titles used in one country may not be appropriate in another. Therefore, you can define job groups to be used by your foreign operating units that contain job titles that are common in their countries.
An operating unit that manages global projects and uses resources located in multiple countries can define a global job group. The operating unit then maps jobs used by its resource-providing operating units to jobs in the global job group. This allows the global project to use the same job definitions for all resources rather than unique jobs that are defined by the resource-owning operating units. These common, or global, jobs ease the maintenance of billing rates and simplify resource reporting.
In order to map jobs from one job group to another, a master job group must be defined. Master job groups are intermediate groupings only and cannot be used for other functional purposes. In Single Business Group Access mode, you can have one master job group for each business group and you can map jobs only within the same business group. In Cross Business Group Access mode, there is only one master job group, and you can map jobs across business groups.
The following table shows sample job groups for a global enterprise with operating units in the U.S. and Europe:
| Job Group | Jobs |
|---|---|
| US Project Job Group | Manager Staff Consultant Senior Consultant Design Engineer Electrical Engineer Construction Worker |
| European Job Group | Chef de Projet Ingenieur Formateur Architecte Ouvrier |
| Global Job Group | Project Manager Consultant Architect Laborer |
| Master Job Group | Master Project Manager Master Consultant Master Architect Master Laborer |
Mapping a job from one job group to a job in another job group is a two-step process. You must first map the job to a job in the master job group. Then you map the master job to the appropriate job in the second job group.
For example, the following tables show the mappings that are required to map the U.S. and European jobs from their respective job groups to global jobs in the global job set.
The following table shows the job mappings from the US Project job group to the Master job group:
| Job in US Project Job Group: | Mapped to Job in Master Job Group: |
|---|---|
| Manager | Master Project Manager |
| Staff Consultant | Master Consultant |
| Senior Consultant | Master Consultant |
| Design Engineer | Master Architect |
| Electrical Engineer | Master Architect |
| Construction Worker | Master Laborer |
The following table shows the job mappings from the European job group to the Master job group:
| Job in European Job Group: | Mapped to Job in Master Job Group: |
|---|---|
| Chef de Projet | Master Project Manager |
| Engenieur Formateur | Master Consultant |
| Architecte | Master Architect |
| Ouvrier | Master Laborer |
The following table shows the job mappings from the Master job group to the Global job group:
| Job in Master Job Group: | Mapped to Job in Global Job Group: |
|---|---|
| Master Project Manager | Project Manager |
| Master Consultant | Consultant |
| Master Architect | Architect |
| Master Laborer | Laborer |
Note the following job mapping rules:
-
Jobs that are not master jobs can be mapped to one and only one master job.
-
Multiple jobs, in and across job groups, can be mapped to the same master job.
-
Master Jobs can be mapped to only one job in each job group.
-
Multiple master jobs can be mapped to the same job.
Related Topics
Job Groups, Oracle Projects Implementation Guide
Jobs, Oracle Projects Implementation Guide
Job Mapping, Oracle Projects Implementation Guide
Using Job Groups in Oracle Projects
You can use job groups in Oracle Projects to specify:
-
Jobs to be used for billing purposes (see Project Types, Oracle Projects Implementation Guide)
-
Jobs to be used for defining job-based bill rate schedules (see Defining Bill Rate Schedules, Oracle Projects Implementation Guide)
-
Job titles used for describing customer invoice lines (see Invoice Formats, Oracle Projects Implementation Guide)
-
Jobs available in resource lists (see Resources and Resource Lists and Defining Resource Lists, Oracle Projects Implementation Guide)
Defining Global Security Profiles
To define global security profiles
-
Navigate to the Global Security Profile window.
Setup > Human Resources > Global Security Profiles
-
Enter a name for the security profile.
-
In the Organization Security region, deselect the View All Organizations check box.
-
Enter the name of the global hierarchy in the Organization Hierarchy field.
-
To allow access to all organizations in the hierarchy, including the top organization, check the Include Top Organization check box.
After you define the security profile, you must associate it with each appropriate user responsibility. Any user that requires global access must use a responsibility that has a global security profile assigned to it.
For more information about defining and assigning security profiles, see Customizing, Reporting, and System Administration in Oracle HRMS: Security.
Multi-Currency Support
In a multinational business environment, employees from locations across the world can report to one operating unit. An operating unit can own projects that are managed and implemented from remote sites. Companies need to do business in multiple currencies. Following are some of the requirements companies have for processing in multiple currencies:
-
Project managers need to report project costs and revenues in the currencies of the countries where work is performed.
-
Agreements, bill rates, and events may need to be set up in the local currency.
-
Invoices need to be issued in the currency required by the suppler.
To enable the flexibility and complexity required for multi-currency processing, Oracle Projects provides multi-currency capability.
This section covers the following topics:
When Currency Amounts Are Calculated
The following table shows when currency conversion occurs for multi-currency transactions.
| Type of Transaction | When Currency Conversion Occurs |
|---|---|
| Pre-approved expenditure entry | During cost distribution in Oracle Projects |
| Transactions imported from Oracle Time and Labor | During cost distribution in Oracle Projects |
| Transactions imported from Oracle Payables | During Transaction Import |
| Material costs imported from Oracle Manufacturing | During Transaction Import |
| Costing transactions imported from external systems: uncosted | During cost distribution in Oracle Projects |
| Costing transactions imported from external systems: costed and unaccounted | During cost distribution in Oracle Projects |
| Costing transactions imported from external systems: costed and accounted | During Transaction Import |
| Funding | When funding lines are saved |
| Revenue | During revenue generation |
| Customer invoices | During invoice generation |
Cross Charge Transactions
The following table shows when currency conversion takes place for cross charge transactions.
| Type of Transaction | When Currency Conversion Occurs |
|---|---|
| Borrowed and lent method | Transfer price converted to project currency and project functional currency during Distribute Borrowed and Lent Amounts process |
| Intercompany billing method | Transfer price is converted to project currency and project functional currency during Generate Intercompany Invoices process |
The currency attributes used to convert the transfer price vary depending on the amount type of the transfer price on the project transaction:
-
If the amount type of the transfer price is Revenue, then the billing currency attributes are used to derive the transfer price.
-
If the amount type of the transfer price is Cost, then the cost currency attributes are used to derive the transfer price.
Converting Multiple Currencies
When you enter transactions in a currency that is different from functional currency or project currency, Oracle Projects must convert the transaction amount to the functional and project currencies.
Transaction amounts are stored in the following currencies:
-
Transaction Currency: The currency in which a project transaction occurs
-
Expenditure Functional Currency: The functional currency of the expenditure operating unit
-
Project Functional Currency: The functional currency of the operating unit that owns the project
-
Project Currency: The user-defined project currency
This section describes how Oracle Projects determines the default conversion attributes it displays during expenditure entry.
For information about currency conversion for transactions imported using Transaction Import, see: Currency Conversion Attributes for Imported Transactions, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.
Determining Currency Conversion Attributes for Entered Transactions
To convert transaction currencies to functional and project currencies, Oracle Projects must first determine the exchange rate type and exchange rate date.
Note: The logic described for determining default values applies to all project transactions. The project functional currencies are the same, then the expenditure functional conversion attributes are used as the project functional values.
Case 5: All Currencies Are Different
Case 1: Project Functional Currency, Expenditure Functional Currency, and Project Currency Are the Same, but Differ from the Transaction Currency
The following logic is used to determine the currency conversion rate type and rate date used in converting the transaction amounts from the transaction currency:
First, the functional currency attributes are determined as follows:
-
If you enter the conversion attribute, that attribute is used for the conversion.
-
By default, the system displays the attribute entered for the task to which the transaction is charged. If you do not override the attribute, the default attribute is used.
-
If no attribute has been entered for the task to which the transaction is charged, the default attribute displayed by the system is the attribute entered at the project level.
-
If there are no defaults entered at the project or task level, the default attribute is the attribute entered in the implementation options for the expenditure operating unit.
These attributes are used to obtain a conversion rate, which is used to convert the transaction currency amount to the project functional currency.
The project functional currency amount is then copied to the expenditure functional currency amount and to the project currency amount.
This logic is summarized in the following table.
| Project Functional Currency | Expenditure Functional Currency and Project Currency |
|---|---|
| The following hierarchy is used: 1. User-entered value 2. Default value from the lowest task 3. Default value from the project 4. Default value from the expenditure operating unit's implementation options |
The project functional currency attributes are used. |
You can override functional currency attributes. You cannot directly override project currency attributes. However, if you change the functional currency attributes, the changes are copied to the expenditure functional currency attributes and project currency attributes.
Case 2: Project Functional Currency and Expenditure Functional Currency Are the Same, but Differ from the Project Currency and Transaction Currency
If the functional currency of the operating unit that incurred the cost is the same as the functional currency of the operating unit to which the cost is charged, but the project currency is different, the following logic is used to determine the rate type and rate date used to convert the transaction amounts from the transaction currency:
The project functional currency attributes are determined as follows:
-
If you enter the conversion attribute, that attribute is used for the conversion.
-
By default, the system displays the attribute entered for the task to which the transaction is charged. If you do not override the attribute, the default attribute is used.
-
If no attribute has been entered for the task to which the transaction is charged, the default attribute displayed by the system is the attribute entered at the project level.
-
If no defaults are entered at the project or task level, the default attribute is the attribute entered in the implementation options for the expenditure operating unit.
The attributes are used to obtain a conversion rate, which is used to convert the transaction currency amount to the project functional currency.
The project functional currency amount is then copied to the expenditure functional currency amount.
The project currency attributes are determined as follows:
-
If you enter the conversion attribute, that attribute is used for the conversion.
-
By default, the system displays the attribute entered for the task to which the transaction is charged. If you do not enter the attribute, the default attribute is used.
-
If no attribute has been entered for the task to which the transaction is charged, the attribute entered for the project is used for the conversion.
-
If there are no defaults entered at the project or task level, the default attribute is the attribute entered in the implementation options for the project operating unit.
The attributes are used to obtain a conversion rate, which is used to convert the transaction currency amount to the project currency.
This logic is summarized in the following table.
| Project Functional Currency (and Expenditure Functional Currency) | Project Currency |
|---|---|
| The following hierarchy is used: 1. User-entered value 2. Default value from the expenditure operating unit's implementation options |
The following hierarchy is used: 1. User-entered value 2. Default value from the lowest task 3. Default value from the project 4. Default value from the project operating unit's implementation options |
You can override both functional and project currency attributes. You cannot directly override the expenditure functional attributes. However, if you change the project functional currency attributes, the changes are copied to the expenditure functional currency values.
Case 3: Project Currency and Expenditure Functional Currency Are the Same, but Differ from the Project Functional Currency and Transaction Currency
In this scenario, the functional currency of the operating unit that incurred the cost is the same as the project currency, but different from the functional currency of the operating unit to which the cost is charged. The following table summarizes the logic that is used to determine the rate type and rate date used to convert the transaction amounts from the transaction currency.
| Project Functional Currency | Expenditure Currency (and Project Currency) |
|---|---|
| The following hierarchy is used: 1. User-entered value 2. Default value from the lowest task 3. Default value from the project 4. Exchange rate date: default value from the expenditure operating unit's implementation options 5. Exchange rate type: default value from the project operating unit's implementation options |
The following hierarchy is used: 1. User-entered value 2. Default value from the lowest task 3. Default value from the project 4. Default value from the expenditure operating unit's implementation options |
You can override both the project functional currency attributes and the expenditure functional currency attributes. You cannot directly override the project currency attributes. However, if you change the expenditure functional currency attributes, the changes are copied to the project currency values.
Case 4: Project Functional Currency and Project Currency Are the Same, but Differ from the Expenditure Functional Currency and Transaction Currency
In this scenario, the functional currency of the operating unit to which the cost is charged is the same as the project currency, but different from the functional currency of the operating unit that incurred the cost. The following table summarizes the logic that is used to determine the rate date and rate type used to convert the transaction amounts from the transaction currency.
| Project Functional Currency (and Project Currency) | Expenditure Functional Currency |
|---|---|
| The following hierarchy is used: 1. User-entered value 2. Default value from the lowest task 3. Default value from the project 4. Exchange rate date: default value from the expenditure operating unit's implementation options 5. Exchange rate type: default value from the project operating unit's implementation options |
The following hierarchy is used: 1. User-entered value 2. Default value from the lowest task 3. Default value from the project 4. Default value from the expenditure operating unit's implementation options |
You can override both the project functional currency attributes and the expenditure functional currency attributes. You cannot directly override the project currency attributes. However, if you change the project functional currency attributes, the changes are copied to the project currency values.
Case 5: All Currencies Are Different
In this scenario, the project functional currency, expenditure functional currency, project currency, and transaction currency are all different. The following table summarizes the logic that is used to determine the rate date and rate type used to convert the transaction amounts from the transaction currency.
| Project Functional Currency | Expenditure Functional Currency | Project Currency |
|---|---|---|
| Following hierarchy is used: 1. User-entered value 2. Default value from the lowest task 3. Default value from the project 4. Exchange rate date: default value from the expenditure operating unit's implementation options 5. Exchange rate type: default value from the project operating unit's implementation options |
Following hierarchy is used: 1. User-entered value 2. Default value from the lowest task 3. Default value from the project 4. Default value from the expenditure operating unit's implementation options |
Following hierarchy is used: 1. User-entered value 2. Default value from the lowest task 3. Default value from the project 4. Default value from the project operating unit's implementation options |
You can override the project functional currency attributes, the expenditure functional currency attributes, and the project functional currency attributes.
Currency Models in Oracle Projects
Oracle Projects uses the following models when converting currency from one denomination to another:
Cost Transaction Currency Model
The illustration Cost Transaction Currency Model shows how Oracle Projects performs three levels of currency conversion to support financial accounting and project management requirements for cost transactions:
-
Reimbursement currency conversion
-
Functional currency conversion
-
Project currency conversion
Cost Transaction Currency Model
Reimbursement Currency Conversion
The purpose of reimbursement currency conversion is to convert expense report items that were entered using receipts in multiple currencies to a single reimbursement currency. These reimbursement currency amounts serve as the basis for expense report reimbursement Additionally, they serve as the expense report transaction currency amounts, which will be the basis for all other subsequent currency conversions.
If the receipt currency for an expense item is different from the reimbursement currency, you must either specify a receipt currency exchange rate value if you want Oracle Projects to perform the conversion, or enter the reimbursement amount directly. For more information, see Entering Expenditures, Oracle Project Costing User Guide.
Functional and Project Currency Conversion
The purpose of functional currency conversion is to convert transaction amounts that were entered using multiple transaction currencies to the functional currency of the expenditure-owning operating unit. The purpose of project currency conversion is to convert transaction amounts that were entered using multiple transaction currencies to the project currency.
When performing functional and project currency conversions for expenditure items, Oracle Projects first looks for functional currency and project currency exchange rate attributes and exchange rate values entered at the transaction level. If you do not enter exchange rate attributes or exchange rate values at the transaction level, Oracle Projects uses the default exchange rate attribute settings at the task, project, and operating unit levels to determine both the functional and project currency exchange rates.
If there is no attribute setting at a particular level, Oracle Projects looks to the next level. If no attributes are specified at the transaction, task, or project level, Oracle Projects uses the default settings specified for the operating unit in Currency Implementation Options. For more information, see Converting Multiple Currencies.
Currency Amounts Stored on Cost Transactions
In the following table, an X denotes the currency amounts that are stored on a particular Oracle Applications entity:
| Entity | Receipt Currency Amount | Cost Transaction or Reimbursement Currency Amount | Cost Functional Amount | Cost Project Amount |
|---|---|---|---|---|
| AP Distribution Line | X | X | X | |
| Journal Entry Line | X | X | ||
| PA Expenditure Item | X | X | X | X |
Customer Billing Invoice Currency Model
The illustration Customer Billing Invoice Currency Model shows how Oracle Projects performs two levels of currency conversion to support financial accounting and project management requirements for customer billing:
-
Invoice currency conversion
-
Receivables functional currency conversion
In addition, Oracle Projects performs an invoice rounding reconciliation process to ensure that converted invoice values remain in agreement throughout the currency conversion process.
Customer Billing Invoice Currency Model
Invoice Currency Conversion
The purpose of invoice currency conversion is to convert invoice amounts from the project currency to an invoice currency using the attributes specified for a customer in the Project Customers window. These attributes may be changed for a specific generated invoice in the Invoice Summary window.
The Generate Draft Invoices process automatically generates invoices using the project currency, then converts them to the currency attributes specified for a customer. If you want to change the attributes of an invoice after it is generated, you must manually initiate the process to recalculate the invoice. When you initiate the recalculation process, you specify, at the invoice level, the currency attributes in the Invoice Summary window.
Receivables Functional Currency Conversion
The purpose of receivables functional currency conversion is to convert released invoice currency amounts from the invoice currency, which is the currency amount that is interfaced to Oracle Receivables, to the functional currency. This conversion is required for financial accounting purposes.
Rounding Reconciliation
When currencies are converted, it is necessary to round currency amounts to the nearest currency unit. For example, when an invoice amount is converted from currency A to currency B and rounded to the nearest unit, and then is converted back to currency A, a rounding difference can occur. The rounding that can occur in conversion can result in different amounts being generated for the same invoice in the same currency.
Oracle Projects handles this situation by determining if rounding will occur later (when the invoice currency amounts are converted to the functional currency in Oracle Receivables). If Oracle Projects determines that rounding will occur during currency conversion, Oracle Projects creates rounding entries at the invoice line level to offset the effects of the currency conversion.
When it interfaces the invoices, Oracle Projects passes the generated rounding entries to Oracle Receivables. When Oracle Receivables creates accounting in Oracle Subledger Accounting for the invoices, it includes both the invoice amounts and the rounding entries. Oracle Subledger Accounting transfers the final accounting to Oracle General Ledger. For more information, see: Invoice Rounding, Oracle Projects Implementation Guide.
Currency Amounts Stored on Customer Billing Transactions
In the following table, an X denotes the currency amounts that are stored on a particular Oracle Applications entity:
| Entity | Invoice Project Currency | Invoice Transaction Currency | Invoice Functional Currency |
|---|---|---|---|
| PA Draft Invoice Item | X | X | |
| AR Invoice Lines | X | X | |
| Journal Entry Line | X | X |
Intercompany Billing Invoice Currency Model
The illustration Intercompany Billing Invoice Currency Model shows how Oracle Projects performs four levels of currency conversion to support financial accounting and project management requirements for intercompany billing:
-
Transfer price currency conversion
-
Intercompany invoice currency conversion
-
Receivables functional currency conversion
-
Payables functional currency conversion
In addition, Oracle Projects performs an invoice rounding reconciliation process to ensure that converted invoice values remain in agreement throughout the currency conversion process, and a prorate process.
Intercompany Billing Invoice Currency Model
Transfer Price Currency Conversion
The purpose of transfer price currency conversion is to convert cross charge transactions from the transfer price currency to the functional currency of the provider operating unit. Transfer price currency is determined by the transfer price basis, which is defined in the Transfer Price Rules window.
-
For a basis of raw or burdened cost, the transfer price currency is the transaction currency of the cross charged transaction.
-
For a basis of revenue, the transfer price currency is the functional currency of the ledger for the receiver operating unit.
-
When a bill rate schedule is used, the transfer price is the standard bill rate schedule currency.
Oracle Projects automatically converts transfer price amounts to the functional currency of the provider operating unit using the transfer price currency conversion attributes defined in Cross Charge Implementation options for the operating unit. The functional currency of the provider operating unit determines the project currency, which is the default currency used to generate invoices for a project.
For more information on transfer pricing, see: Transfer Pricing, Oracle Project Costing User Guide. For information on defining transfer price currency conversion attributes, see: Define Cross Charge Implementation Options, Oracle Projects Implementation Guide.
Intercompany Invoice Currency Conversion
The Generate Intercompany Invoices process automatically generates intercompany invoices using the project currency of the provider. The purpose of intercompany invoice currency conversion is to convert intercompany invoices to the currency attributes specified for the receiving operating unit in the intercompany project customer setup form. If you want to change the attributes of an invoice after it is generated, you must manually initiate the process to recalculate the invoice, and specify the invoice level currency attributes in the Invoice Summary window.
Receivables Functional Currency Conversion
The purpose of receivables functional currency conversion is to convert released invoice currency amounts from the invoice currency, which is the currency amount that is interfaced to Oracle Receivables, to the functional currency. This conversion is required for financial accounting purposes.
Payables Functional Currency Conversion
The provider's receivables invoice currency is used to create the receiver's payables invoice currency amounts. Therefore, the purpose of the payables functional currency conversion is to convert the receiver's payables invoice amounts to the receiver's functional currency. The conversion is required for financial accounting purposes.
The invoice currency amount is converted to the functional currency based on the default payables currency conversion attributes defined in Oracle Payables for the receiver's operating unit.
Rounding Reconciliation
When currencies are converted, the resulting amount must be rounded to the nearest currency unit. For example, when an invoice amount is converted from currency A to currency B and rounded to the nearest unit, and then is converted back to currency A, a rounding difference can occur. The rounding that can occur in conversion can result in different amounts being generated for the same invoice in the same currency.
Oracle Projects handles this situation by determining if rounding will occur later (when the invoice currency amounts are converted to the functional currency in Oracle Receivables). If Oracle Projects determines that rounding will occur during currency conversion, then rounding entries are created at the invoice line level to offset the effects of the currency conversion. When Oracle Receivables generates accounting events for the invoices, it includes both the invoice amounts and the rounding entries. Oracle Subledger Accounting uses the accounting events to create the final accounting that it transfers to Oracle General Ledger.
For more information, see: Invoice Rounding, Oracle Projects Implementation Guide
Reporting Currencies
Each ledger is defined with a ledger currency that is the primary record-keeping currency used to record business transactions and accounting data within Oracle General Ledger. If you also need to maintain and report accounting records in one or more reporting currencies, then you can do this by defining one or more reporting currencies for the ledger. You can perform financial reporting in Oracle General Ledger using the ledger currency or a reporting currency.
Unlike secondary ledgers, reporting currencies only differ by currency from their source ledger. They share the same chart of accounts, accounting calendar and period type combination, subledger accounting method, and ledger processing options.
Typically, you use reporting currencies in the following scenarios:
-
You operate in a country with an unstable currency and you need to concurrently report your business in a more stable currency.
-
Your company is multinational, and you need to report financial information in a currency other than that of the transaction or your functional currency.
-
You operate in a country that is part of the European Monetary Union (EMU), and you want to concurrently report in Euro.
To use reporting currencies, you must define reporting currencies for your ledger in the Accounting Setup Manager.
Oracle Projects generates accounting events that Oracle Subledger Accounting uses to create the final accounting that it transfers to Oracle General Ledger. For subledger-level reporting currencies, Oracle Subledger Accounting automatically performs the reporting currency conversion for the subledger journals.
Note: The generate asset lines in Oracle Projects process calculates reporting currency amounts for the asset lines. For additional information, see: Generate Asset Lines.
Note: If you allow users to make adjustments in Oracle Projects to expenditure items that represent receipts, receipt nonrecoverable tax, or exchange rate variances, then Oracle Projects does not perform accounting for adjustments in the following ledgers:
-
Reporting currency ledgers
-
Secondary ledgers if the secondary ledger currency differs from the primary ledger currency
The profile option PA: Allow Adjustments to Receipt Accruals and Exchange Rate Variance enables you to control whether users can adjust these expenditure items when exchange rate variance exists and you convert journals to another currency. For additional information, see: Profile Options, Oracle Projects Implementation Guide, and Restrictions to Supplier Cost Adjustments, Oracle Project Costing User Guide.
If you plan to use reporting currencies with Oracle Projects, see information about reporting currencies in the Oracle Financials Implementation Guide.
Multilingual Support
Oracle Applications supports MLS (Multiple Language Support) so you can run Oracle Applications in multiple languages from a single installation of the applications in one database instance.
For a detailed description of the MLS features available in Oracle Applications, see: Oracle Applications Concepts Manual.
If you use MLS, you can define MLS-enabled entities in each of your installed languages by selecting Translations from the toolbar or menu. This enables you to enter a name and description in other languages. Then, when a user selects from a list of values, the entities appear on the list in the user's language.
The MLS-enabled entities in Oracle Projects are:
-
PA_AMOUNT_TYPES_TL
-
PA_CI_TYPES_TL
-
PA_GANTT_BAR_STYLES_TL
-
PA_GANTT_CONFIG_TL
-
PA_GANTT_VIEWS_TL
-
PA_PROJECTS_ERP_EXT_TL
-
PA_PROJECT_ROLE_TYPES_TL
-
PA_UTIL_CATEGORIES_TL
-
PA_WORK_TYPES_TL
In addition, Oracle Projects enables MLS for all setups that are modeled as lookups. For more information, see Oracle Projects Lookups: Oracle Projects Implementation Guide.
MLS for Customer Invoices
You can enter the translated text in the customer's billing language for each invoice line. Oracle Receivables prints the translated text on the invoice when you print the invoice in the customer's billing language.
Every customer invoice generated in Oracle Projects will be linked to the language associated with the Bill Site of the invoice. (The Bill Site field for an invoice is specified for the customer in the Project Customer window, available from the Customers and Contacts option in the Projects window.) You specify the language of the site in the Customers window in Oracle Receivables. For more information, see: Oracle Receivables Users Guide.
The system generates invoice line descriptions in the base language. You must enter the translation for this description in the Translated Text field (in the Invoice Lines folder) in the Invoice Lines window. If you have update privileges for the project, you can enter the translated description any time before the invoice is interfaced to Oracle Receivables. You must enter the translation to print the invoice in a customer language that is different from the base language. If you do not enter the translation, the invoice line descriptions print in the base language even if you print the invoice in the customer's language.
For credit memo lines, Oracle Projects copies the translated text from the credited invoice lines. You can change this value subject to the restrictions on invoicing (above).
The translated text is interfaced to Oracle Receivables along with the rest of the invoice. Oracle Receivables uses the translated text and the translated customer name when printing invoices in the customer's language.
Autoaccounting and MLS
If you use lookup sets for any of the following parameters in your AutoAccounting rules, you must set up these lookup sets in the base language only:
-
Revenue Category
-
Project Organization
-
Task Organization
-
Task Service Type
-
Expenditure Organization
-
Non-Labor Resource Org.
-
Event Organization
-
Provider Operating Unit
-
Receiver Operating Unit
-
Provider Organization
-
Receiver Organization
-
Customer Name
Decentralized Invoice Processing and MLS
If you use decentralized processing for your invoices in Oracle Projects and Oracle Receivables, the system creates transaction types in the base language only. This affects your invoicing organizations when you run the PRC: Create Invoice Organization Transaction Types process. You can translate the name from the base language to other languages, as required, in Oracle Receivables.