Skip Headers

Oracle Projects Implementation Guide
Release 12.1
Part Number E13582-04
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Implementing Oracle Project Billing

This chapter contains instructions for implementing Oracle Project Billing.

This chapter covers the following topics:

Oracle Project Billing Implementation Checklists

Oracle Project Billing, together with Oracle Project Costing, provides a complete, integrated project billing solution. Oracle Project Billing can automate revenue generation, simplify your client invoicing, improve your cash flow, and measure the performance and profitability of your contract projects. Oracle Project Billing is part of the Oracle E-Business Suite, an integrated set of applications that are engineered to work together.

For general information about the Oracle Projects implementation checklists, see Overview of Setting Up Oracle Projects.

Note: To find out how to access a window, refer to the Navigation Paths index, Oracle Projects Fundamentals.

Oracle Project Billing Product Implementation Checklist

The following checklist shows the steps required to implement Oracle Project Billing. The product setup checklist is organized by area of functionality. The Required/Optional column indicates if the step is required or optional for use of the product.

To implement Oracle Project Billing, complete the steps in the following order:

  1. Licensing

  2. Revenue and Invoicing

  3. Agreements and Funding

  4. Customers

  5. Accounting for Revenue and Billing

1. Licensing

The following table lists the step required for licensing:

Step Description Required /Optional Setup Level Responsibility
PJB-P1.1 Set the profile option PA: Licensed to Use Project Billing Required Site System Administrator

Note: For details about the licensing step, see Licensing Oracle Project Billing.

2. Revenue and Invoicing

The following table lists the steps required for revenue and invoicing:

Step Description Required /Optional Setup Level Responsibility
PJB-P2.1 Define Receivables System Options Required OU Receivables Manager (Defined in Oracle Receivables)
PJB-P2.2 Set up tax in Oracle E-Business Tax and assign tax classification codes Required OU Tax Managers
PJB-P2.3 Define payment terms Required Site Projects Implementation Super User
PJB-P2.4 Define rate schedules Optional OU (based on PJF) Projects Implementation Super User
PJB-P2.5 Define invoice formats Required Site Projects Implementation Super User
PJB-P2.6 Define invoice print method Optional Site Projects Implementation Super User
PJB-P2.7 Define credit types Required Site Projects Implementation Super User
PJB-P2.8 Define event types Optional Site Projects Implementation Super User
PJB-P2.9 Define and assign billing assignments Optional Site Projects Implementation Super User
PJB-P2.10 Define percent complete revenue accrual and invoicing options Optional Site Projects Implementation Super User
PJB-P2.11 Set the profile option PA: Maintain Unbilled Receivables and Unearned Revenue Balances Optional Site System Administrator
PJB-P2.12 Set the profile option: PA Interface Unreleased Revenue to GL Optional OU (can vary by OU) System Administrator
PJB-P2.13 Implement billing extensions Optional Site Projects Implementation Super User
PJB-P2.14 Implement labor billing extension Optional Site Projects Implementation Super User
PJB-P2.15 Implement billing cycle extension Optional Site Projects Implementation Super User
PJB-P2.16 Implement retention billing extension Optional Site Projects Implementation Super User
PJB-P2.17 Implement automatic invoice approve/release extension Optional Site Projects Implementation Super User
PJB-P2.18 Implement the AR transaction type extension Optional Site Projects Implementation Super User
PJB-P2.19 Implement the output tax extension Optional Site Projects Implementation Super User
PJB-P2.20 Implement revenue-based cost accrual extension Optional Site Projects Implementation Super User
PJB-P2.21 Implement cost accrual billing extension Optional Site Projects Implementation Super User

Note: For details about the revenue and invoicing steps, see Revenue and Invoicing.

3. Agreements and Funding

The following table lists the steps required for agreements and funding:

Step Description Required /Optional Setup Level Responsibility
PJB-P3.1 Define agreement types Required Site Projects Implementation Super User
PJB-P3.2 Define agreement templates Optional OU Projects Implementation Super User
PJB-P3.3 Enter prepayment receivable activities Optional OU Receivables Super User
PJB-3.4 Implement funding revaluation factor extension Optional Site Projects Implementation Super User
PJB-P3.5 Implement Advance Required extension Optional Site Projects Implementation Super User

Note: For details about the agreements and funding steps, see Setting Up for Agreements and Funding.

4. Customers

The following table lists the step required for customers:

Step Description Required /Optional Setup Level Responsibility
PJB-P4.1 Define customers Required OU Receivables Manager

Note: For details about the customer step, see Customers.

5. Accounting for Revenue and Billing

These steps describe setting up accounting for revenue and billing in Oracle Subledger Accounting and Oracle Projects AutoAccounting.

The following table lists the steps required to set up accounting for revenue and billing in Oracle Subledger Accounting:

Step Description Required /Optional Setup Level Responsibility
PJB-P5.1 Define custom sources Optional Ledger Projects Implementation Super User
PJB-P5.2 Define journal line types Optional Ledger Projects Implementation Super User
PJB-P5.3 Define journal entry descriptions Optional Ledger Projects Implementation Super User
PJB-P5.4 Define mapping sets Optional Ledger Projects Implementation Super User
PJB-P5.5 Define account derivation rules Optional Ledger Projects Implementation Super User
PJB-P5.6 Define journal lines definitions Optional Ledger Projects Implementation Super User
PJB-P5.7 Define application accounting definitions Optional Ledger Projects Implementation Super User
PJB-P5.8 Assign application accounting definitions to a subledger accounting method Optional Ledger Projects Implementation Super User
PJB-P5.9 Assign a subledger accounting method to a ledger Optional Ledger Projects Implementation Super User
PJB-P5.10 Update post-accounting program assignments Optional Ledger Projects Implementation Super User

The following table lists the steps required to set up accounting for revenue and billing in Oracle Projects AutoAccounting:

Step Description Required /Optional Setup Level Responsibility
PJB-P5.11 Set the profile option PA: Selective Flexfield Segment for AutoAccounting Required Site (cannot vary by OU) System Administrator
PJB-P5.12 Define accounting for labor revenue Required OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.13 Define accounting for expense report revenue Required OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.14 Define accounting for usage revenue Required OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.15 Define accounting for miscellaneous revenue Required OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-5.16 Define accounting for burden transaction revenue Required OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.17 Define accounting for inventory revenue Required OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.18 Define accounting for work in process revenue Required OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.19 Define accounting for supplier invoice revenue Required OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.20 Define accounting for event revenue Required OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.21 Define accounting for unbilled receivables, unearned revenue, and receivables Required OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.22 Define accounting for realized gains Optional OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.23 Define accounting for realized losses Optional OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.24 Define accounting for interproject transactions Optional OU (AutoAccounting, based on PJF) Projects Implementation Super User
PJB-P5.25 Define invoice rounding account Required OU Projects Implementation Super User
PJB-P5.26 Define accounting for invoice write-offs Required OU Projects Implementation Super User

Note: For details about setting up AutoAccounting for revenue and billing, see Accounting for Revenue and Billing.

Oracle Project Billing Feature Implementation Checklist

The following checklist shows the steps required to implement each Oracle Project Billing feature. The list is organized by feature. The Required/Optional column indicates if the step is required or optional for use of each feature.

To implement Oracle Project Billing features, complete the steps in the following order:

  1. Inter-Project Billing

  2. Customer Billing Retention

  3. Integration with Oracle Receivables

1. Inter-Project Billing

The following table lists the steps required for inter-project billing:

Step Description Required /Optional Setup Level Responsibility
PJB-F1.1 Define additional expenditure types, agreement types, billing cycles, invoice formats, and supplier types for inter-project billing Optional Site Projects Implementation Super User
PJB-F1.2 Define an internal supplier for the provider operating unit (global setup) Required OU Purchasing Super User, Payables Manager
Defined in Oracle Payables or Oracle Purchasing
PJB-F1.3 Define an internal customer for the receiver operating unit (global setup) Required OU Receivables Manager
PJB-F1.4 Define supplier sites for internal suppliers (for each receiver operating unit) Required OU Purchasing Super User, Payables Manager
Defined in Oracle Payables or Oracle Purchasing
PJB-F1.5 Define bill to and ship to sites for internal customer (for each provider operating unit) Required OU Receivables Manager
PJB-F1.6 Define internal billing implementation options (for each operating unit) Required OU Projects Implementation Super User
PJB-F1.7 Define provider and receiver controls (for each operating unit) Required OU Projects Implementation Super User
PJB-F1.8 In Oracle E-Business Tax, set up tax for internal Oracle Receivables invoices and configure for each provider operating unit Required OU Tax Managers
PJB-F1.9 In Oracle E-Business Tax, set up tax for internal Oracle Payables invoices and configure for each receiver operating unit Required    
PJB-F1.10 Define provider and receiver projects Required OU Projects Implementation Super User
PJB-F1.11 Define the Supplier Invoice Charge Account for internal invoicing Required OU Workflow Builder
PJB-F1.12 Implement Payables Open Interface Workflow Required Site Workflow Builder
PJB-F1.13 Implement Inter-Project Billing extensions Optional Site Projects Implementation Super User

Note: For details about the inter-project billing steps, see Setting Up for Inter-Project Billing.

2. Customer Billing Retention

The following table lists the steps required for customer billing retention:

Step Description Required /Optional Setup Level Responsibility
PJB-F2.1 Define billing implementation options Required OU Projects Implementation Super User
PJB-2.2 Define retention invoice format Required OU Projects Implementation Super User
PJB-2.3 Define accounting for unbilled retention Optional OU Projects Implementation Super User

Note: For details about the customer billing retention steps, see Customer Billing Retention.

3. Integration with Oracle Receivables

The following table lists the steps required for integration with Oracle Receivables:

Step Description Required /Optional Setup Level Responsibility
PJB-F3.1 Install and implement Oracle Receivables Required OU Receivables Manager
defined in Oracle Receivables
PJB-F3.2 Define transaction types Required OU Receivables Manager
defined in Oracle Receivables
PJB-F3.3 Set profile options for project invoices Required OU System Administrator
PJB-F3.4 Define Automatic Accounting in Receivables Optional OU Receivables Manager
defined in Oracle Receivables
PJB-F3.5 Define salespersons for sales credit Optional OU Receivables Manager
defined in Oracle Receivables
PJB-F3.6 Implement Receivables installation override extension Optional Site Receivables Manager

Note: For details about the Oracle Receivables integration steps, see Integration with Oracle Receivables.

Related Topics

Overview of Setting Up Oracle Projects

Licensing Oracle Project Billing

The following instructions give details about the Licensing steps in the Oracle Project Billing Product Implementation Checklist.

To indicate to the system that Project Billing is licensed, set the profile option PA: Licensed to Use Project Billing.

See: PA: Licensed to Use Project Billing.

Revenue and Invoicing

The following instructions give details about the Revenue and Invoicing steps in the Oracle Project Billing Product Implementation Checklist.

These instructions give you the information you need to create the settings and basic information required for revenue and invoicing.

Defining Receivables System Options

Start by specifying the system parameters for Oracle Projects. If you have installed the standalone version of Oracle Projects, these system parameters provide default values required for customer entry.

Use the System Options window to view and update the system options used by Oracle Receivables. See: System Options, Oracle Receivables Implementation Guide.

Purge Interface Tables Option

You set up Oracle Receivables AutoInvoice to purge rows from its interface tables. When you tie back invoices, Oracle Projects processing requires that successfully processed rows be purged from the Receivables interface tables. To do so, enable the Purge Interface Tables option for Oracle Projects. This option is located in the AutoInvoice zone of the Invoices and Customers region.

Require Salesperson Option

If you are interfacing salesperson information, enable the Require Salesperson option. This option is located in the Miscellaneous tab.

For more setup information, see: Salespersons and Credit Types.

Fremont Corporation Receivables Options

Fremont Corporation's implementation team enables the following invoice options:

Applying Tax to Project Invoices

Oracle Projects and Oracle Receivables allow you to tax customers based on tax requirements of your company, your customers, and tax authorities.

Customers and tax authorities may have many different tax requirements. For example:

Oracle Projects enables you to specify the tax information assigned to each invoice line on a line-by-line basis. Tax information for an invoice line consists of the tax classification code. Oracle Projects derives the default tax classification code on an invoice line based on the hierarchy for tax options that you define for Oracle Projects and the project’s operating unit in Oracle E-Business Tax. You can override the default tax classification code.

To ensure that every project invoice line has a tax classification code, you must perform certain setups in Oracle Projects, Oracle E-Business Tax, and Oracle Receivables. Oracle E-Business Tax uses the tax classification code to apply tax rules and rate to determine tax amounts.

Note: While setting up taxes for Oracle Projects, note that Oracle Project Billing does not support inclusive tax codes.

Setting Up Tax in Oracle E-Business Tax

You must complete the following setup steps in Oracle E-Business Tax to create and derive default tax classification codes for use on customer invoices. For more information on setting up taxes and application tax options, see the Oracle E-Business Tax User Guide.

Setting Up Tax

Use the Oracle E-Business Tax Regime to Rate Flow business process to set up tax rates for the combination of a tax regime, tax name, and tax status. For every tax rate that you define, Oracle E-Business Tax stores the value as identical application lookup codes; one under the lookup type of ZX_INPUT_CLASSIFICATION and the other under the lookup type of ZX_OUTPUT_CLASSIFICATION. For more information on using the Regime to Rate Flow process, see the Oracle E-Business Tax User Guide.

Note: To ensure the calculation of identical tax amounts on internal Oracle Receivables and Oracle Payables invoices for intercompany billing, subscribe the provider and receiver operating units to the tax regime with Configuration for Taxes and Rules as Common Configuration and define taxes for the tax regime and Global Configuration Owner in Oracle E-Business Tax.

Using Application Tax Options for Default Tax Classification Codes

The hierarchy of tax options in Oracle E-Business Tax determines the default tax classification code on a customer invoice. You can configure the hierarchy of tax options for the Oracle Projects application and the provider operating unit. You can associate a tax classification code with one or more of the available tax option sources for project invoices. For example, you can assign a tax classification code to the following tax option sources.

The Generate Draft Invoices process uses the Application Tax Options hierarchy in Oracle E-Business Tax to find and assign the default tax classification code to an invoice line. For more information, see the Oracle E-Business Tax User Guide.

Using Profile Options to Override Defaults

You can set up the following Oracle E-Business Tax profile options to override the derivation of default tax classification codes on project invoices.

You can set these options at the site, application, responsibility, and user levels. These profile options enable you to review the generated invoice in Oracle Projects and select any other tax rate or tax classification code for the recalculation of tax amounts. You can only select tax rates or tax classification codes that your operating unit is subscribed to.

For more information on profile options, see the Oracle E-Business Tax User Guide.

Assigning Tax Classification Codes

You can assign tax classification codes in Oracle E-Business Tax to the following Application Tax Options hierarchy sources. Based on the hierarchy that you define for Oracle Projects and the project operating unit, Oracle E-Business Tax uses the first available tax classification code that it finds as the default tax classification code for the project invoice.

Setting Up Tax in Oracle Projects

Follow these steps in Oracle Projects to set up tax for project invoices.

Assigning Tax Classification Codes

Assign a tax classification code to the following sources in Oracle Projects that are available in the Application Tax Options hierarchy of Oracle E-Business Tax.

Setting up Tax in Oracle Receivables

Follow these steps in Oracle Receivables to ensure that the tax classification code assigned to the invoice in Oracle Projects is used to calculate taxes.

Enabling Default Tax Classification for Oracle Receivables Transaction Types

During the Interface Invoices to Receivables process, Oracle Projects assigns an Oracle Receivables transaction type to each invoice. These transaction types have the Default Tax Classification check box disabled by default. The Default Tax Classification check box works as follows:

Review invoice transaction types in Oracle Receivables and ensure that the Default Tax Classification check box is set correctly for your business needs.

Processing Taxable Invoice Lines

To process taxable customer invoices, you perform the following steps in Oracle Projects:

Generating an Invoice

The Generate Draft Invoices process groups expenditure items, events, and retention into invoice lines based on the invoice formats. The process assigns default tax classification codes based on the hierarchy of tax options that you defined for Oracle Projects in Oracle E-Business Tax.

The process assigns tax exemptions based on the exemptions you have defined for the Customer or Customer Site in Oracle E-Business Tax.

Review Invoice Tax Classification Codes

You can review the tax classification codes in the draft invoice lines using the Invoice Review windows. You can override invoice line tax classification codes, if you are permitted to do so by the Oracle E-Business Tax profile options and project security.

After you release an invoice, you cannot change the tax classification codes.

Interface Invoices to Oracle Receivables

After you release an invoice, you interface invoices to Oracle Receivables. The Interface Invoices to Receivables process moves invoice lines and tax classification codes to the Oracle Receivables interface tables.

The Oracle Receivables AutoInvoice process creates invoices in Oracle Receivables from the invoice lines in the interface table.

Oracle Receivables uses the tax classification codes for each invoice to retrieve calculated tax amounts from Oracle E-Business Tax.

Report and View Tax Information

You can report company tax liabilities using Oracle Receivables reports.

You can print tax information on a customer invoice using the Oracle Receivables invoice printing program or using a custom invoice printing program that reports tax information from the Oracle Receivables invoice tables.

Related Topics

Using Profile Options to Override Defaults

Reviewing Invoices, Oracle Projects Billing User Guide

Create Invoice Organization Transaction Types Process, Oracle Projects Fundamentals

For more information on transaction types, see the Oracle Receivables Implementation Guide

Payment Terms

You associate payment terms with your customer invoices to determine your customer's payment schedule. You specify payment terms when you define agreement types and agreements in Oracle Projects. These payment terms are used for each invoice that is funded by a particular agreement. Payment terms can include discount percents for early payment and due dates for a total invoice or for parts of an invoice.

You use the Oracle Receivables Payment Terms window to define payment terms that reflect your company's procedures.

Fremont Corporation Payment Terms

Since Fremont Corporation uses 30 Net which is predefined, the implementation team does not define any other payment terms.

Related Topics

Agreement Types

Payment Terms, Oracle Receivables Implementation Guide

Defining Bill Rate Schedules

Rate schedules are defined for costing, billing. and work and financial planning. As part of your implementation of Oracle Project Billing, you can define bill rate schedules A bill rate schedule maintains the rates and percentage markups over cost that you charge clients for your labor and non-labor expenditures.

You can define or copy rate schedules for your entire organization. You can also define or copy rate separate rate schedules for individual business units.

For detailed information about defining bill rate schedules, see: Rate Schedule Definition.

For additional discussion regarding rates in Oracle Projects, please see Rates: Oracle Project Fundamentals.

Bill Rates on Invoices

If you set up an invoice format that specifies Bill Rate or Bill Rate Prorated on an invoice line, select the bill transaction currency as well, to display the bill rate currency.

Fremont Corporation Bill Rate Schedules

Fremont Corporation uses the following bill rate schedules:

The following table shows Fremont's bill rate schedules:

Bill Rate Schedule Attributes: Standard Schedule Hazardous Work Schedule Block Rates Schedule Standard Non-Labor Schedule
Organization: Fremont Corporation Environmental Fremont Construction Fremont Corporation
Schedule Name: Standard Hazardous Work Block Rates Standard Non-Labor
Description: Corporate standard bill rates Hazardous area bill rates Construction block rate schedule Corporate standard non-labor schedule
Schedule Type: Employee Employee Job Non-Labor
Job Group:     Engineering  

The following table shows the bill rates defined under the Standard and Hazardous Work bill rate schedules:

Rate Schedule Employee Bill Rate
Standard James Robinson 120/hr
Standard Donald Gray 140/hr
Standard Amy Marlin 130/hr
Hazardous Work James Robinson 170/hr
Hazardous Work Donald Gray 190/hr

In addition, the following bill rates are defined for jobs under the Block Rates schedule:

Job Bill Rate
Senior Engineer 140/hr
Staff Engineer 85/hr
Principal 200/hr
Staff Clerk 55/hr
Staff Draftsman 75/hr
Senior Consultant 150/hr
Staff Consultant 95/hr
Principal Consultant 200/hr

The following table shows the bill rates and markup percentages assigned to each expenditure type under the Standard Non-Labor bill rate schedule:

Expenditure Type Resource Bill Rate Markup Percentage
Air Travel     5
Automobile Rental     5
Personal Auto Use   0.26/mi  
Meals     5
Entertainment     0
Other Expense     5
Computer Services   10/hr  
Computer Services VAX 9000 40/hr  
Computer Services HQ1 Seq 30/hr  
Computer Services Sparc 15/hr  
Vehicle   90/day  
Vehicle Van 70/day  
Field Equipment   8/hr  
Other Asset     20
Consulting     30
Construction     40
Other Invoice     20
Supplies     10

Related Topics

Standard Rate Schedules Listing, Oracle Projects Fundamentals

Invoice Formats

Invoice Formats

An invoice format determines how Oracle Projects creates an invoice line. You can define different formats for labor, non-labor, retention, and retention billing invoice line items, and specify if you want to use the format for customer invoices, intercompany invoices, or both, how you want to summarize expenditure items, and the fields you want an invoice line to display. You can also include free-form text on an invoice line.

You can use customer invoice formats only for regular contract projects, and intercompany invoice formats only for invoices generated by intercompany billing projects. You can also share invoice formats between customer and intercompany invoices.

The grouping option specifies which expenditure items you want to summarize in an invoice line, and whether an invoice line item is labor, non-labor, or retention. Which grouping options you can select depends on the purpose of the invoice format.

The choice of fields you can display in an invoice line depends on the purpose of the invoice format and which grouping option you choose.

Defining Invoice Formats

To define an invoice format:

  1. In the Invoice Formats window, specify an invoice format name, format type, use, and a grouping option. You must also specify a From effective date.

  2. Specify start and end positions for each field you want to include in the invoice line and any text that you want to display in the line.

  3. Save your work.

Invoice Formats Window Reference

Name. Enter a unique, descriptive name for this invoice format.

Format Type. Select a format type. The format type controls the invoice formats you see for labor, non-labor, retention , and retention billing when you enter invoice formats using the Projects window.

Effective From. Enter the date range during which you want the invoice format to be effective.

Use For. Select an option to indicate if you want to use this invoice format for customer invoices, intercompany invoices, or both.

Grouping. Enter a grouping option for this invoice format. You can choose any grouping option available for this type of invoice. A grouping option specifies what fields are the primary grouping of items into invoice lines, and is based on the funding level of the project. A project budgeted at the top task will have a top task grouping rule.

Invoice Format Details. Enter the items you want to appear in the invoice line description:

Start and End. Specifies where you want this field to appear on the invoice line. Enter numbers between 1 and 240.

Field Name. Enter the name of the field that you want to appear on the invoice line. You can choose any invoice line field available for grouping option or the invoice format. However, if you are defining an invoice format that supports both customer and intercompany invoices, you can select only those fields that are shared by the two formats. Enter Text if you want to enter literal text in this position.

When you group invoice lines by expenditure category or expenditure type and choose to display units on the invoice, the system groups invoice transactions based on a combination of the expenditure category or expenditure type, and the transaction unit of measure. Therefore, if more than one unit of measure is associated with the transactions that relate to an expenditure category or expenditure type, then the system displays separate invoice lines for each combination of expenditure category or expenditure type, and unit of measure.

When you select Organization as Field, the invoice line displays Override to Organization in the invoice line description. If no override organization is defined, the invoice line displays Non Labor Resource Organization as text, which is defined only for usages.

If the process is unable to retrieve any value for invoice line description, No Description is displayed as the invoice line text.

Note: If you select Bill Rate or Bill Rate Prorated, select the bill transaction currency, as the bill rate is displayed in the bill transaction currency.

Text. Enter the literal text that you want Oracle Projects to display as the value for this field. Oracle Projects skips this field unless you have entered Text in the previous field.

Right Justify Select if you want this field value to appear right justified between the specified start and end positions.

Oracle Projects enables this option for all numeric field values. Otherwise, Oracle Projects disables it.

About Invoice Formats for Intercompany Billing

If you are using intercompany billing, define an invoice format for summarizing cross-charge transactions. Depending on the requirements of the receiver operating units, you may need to define several invoice formats.

Formats defined for use by intercompany invoices cannot have a type of Retention.

Although one invoice format can support both customer and intercompany invoices, the list of values in the Field Name area will only include those values that are shared by the two formats.

Fremont Corporation Invoice Formats

Fremont Corporation uses three labor invoice formats: two non-labor invoice formats, one invoice format for retention, and one invoice format for retention billing. Invoice formats for Freemont are shown in the following table:

Invoice Format Name Format Type Grouping
Job Labor job
Employee Labor Employee
Job by Task Labor Top Task, Job
Expenditure Type Non-Labor Expenditure Type
Expenditure Type by Task Non-Labor Top Task, Expenditure Type
Retention Percentage Retention Retention
Retention Billing Retention Billing Retention Billing

Job Invoice Format Details

The details of the Job invoice format are shown in the following table:

Start End Field Name Text Right Justify
1 30 Job (blank) Disabled
35 50 Total Hours (blank) Enabled
52 57 Text Hours Disabled

Employee Invoice Format Details

The details of the Employee invoice format are shown in the following table:

Start End Field Name Text Right Justify
1 30 Employee Full Name (blank) Disabled
40 50 Billing Title (blank) Disabled
55 70 Total Hours (blank) Enabled
72 77 Text Hours Disabled

Job by Task Invoice Format Details

The details of the Job by Task invoice format are shown in the following table:

Start End Field Name Text Right Justify
1 25 Top Task Name (blank) Disabled
30 40 Job (blank) Disabled
45 60 Total Hours (blank) Enabled
62 67 Text Hours Disabled

Expenditure Type Invoice Format Details

The details of the Expenditure Type invoice format are shown in the following table:

Start End Field Name Text Right Justify
1 30 Expenditure Type (blank) Disabled
35 40 Total Amount (blank) Enabled
42 50 Units (blank) Disabled

Expenditure Type by Task Invoice Format Details

The details of the Expenditure Type by Task invoice format are shown in the following table:

Start End Field Name Text Right Justify
1 30 Top Task Name (blank) Disabled
35 50 Expenditure Type (blank) Enabled
55 60 Non-Labor Resource (blank) Disabled
62 67 Total Amount (blank) Enabled
70 75 Units (blank) Disabled

Retention Invoice Format Details

The details of the Retention Invoice format are shown in the following table:

Start End Field Name Text Right Justify
1 50 Withholding Term (blank) Enabled
55 70 Withholding Basis Amount (blank) Disabled
72 80 Withholding Percentage / Amount (blank) Disabled
85 90 Invoice Processing Currency (blank) Disabled
95 115 Text Retention Line Disabled

Retention Billing Format Details

The details of the Retention Billing invoice format are shown in the following table:

Start End Field Name Text Right Justify
1 30 Retention Billing Method (blank) Enabled
35 50 Method Value (blank) Disabled
55 70 Total Withheld Amount (blank) Disabled
75 90 Retention Billing Amount (blank) Disabled
95 100 Retention Billing Percentage (blank) Disabled
105 110 Invoice Processing Currency (blank) Disabled

Related Topics

Approving, Releasing, and Printing Invoices, Oracle Project Billing User Guide

Invoice Formats Listing, Oracle Projects Fundamentals

Determining Your Invoice Printing Method

Oracle Projects provides you with powerful methods to create, adjust, review, approve, and print invoices.

You should determine your company's invoice printing strategy as part of your implementation process.

Considerations for your Company's Invoice Printing Strategy: Company Requirements and Constraints

You need to consider your company's invoice printing requirements and constraints as factors in formulating an appropriate invoice printing strategy for your company. These considerations may include:

Oracle Applications Printing Options

Oracle Projects interfaces invoices to Oracle Receivables for printing. You can print invoices from Oracle Projects or from Oracle Receivables.

Oracle Receivables provides an invoice printing program. You should examine the format of the Oracle Receivables invoices and the invoice printing program and determine if it meets your business requirements. If it does not, you can modify the standard report or create a new report.

You can print invoices from Oracle Projects. To do this, you need to write a custom invoice printing program. The benefits of printing invoices from Oracle Projects rather than Oracle Receivables is that you can print invoices once they are released in Oracle Projects without waiting until the invoices are interfaced to Oracle Receivables.

You may create a custom report which you use to download released invoices data from Oracle Projects into a spreadsheet, word processor, or any other tool to do flexible formatting.

Note: If you print or download invoices from Oracle Projects, you should process only released invoices. With this precaution, you ensure that the invoice is not changed after it is printed. Invoices cannot be changed once they are released in Oracle Projects; the released invoices may be credited but not changed.

Tip: If you print or download invoices from Oracle Projects, you can record the date that the invoice is processed using the Extracted Date column in the draft invoices table. Oracle Projects does not currently use this column.

If some invoice lines have tax information, you must print the related invoices after they are interfaced to Oracle Receivables, because the Oracle Receivables AutoInvoice program calculates the tax amounts for these invoices. You can print the invoices from Oracle Receivables or from Oracle Projects. If you print from Oracle Projects, you need to report the tax amounts, rates, and accounting from the Oracle Receivables invoice tables.

If you want to print the remit to address on the invoice, you must print invoices after the invoices are interfaced to Oracle Receivables because Oracle Receivables determines the remit to address for invoices.

You can print invoices in the customer's language. For more information, see: Multilingual Support in Oracle Projects, Oracle Projects Fundamentals.

Invoice Formats as Part of Your Company's Invoice Printing Solution

All of these invoice printing strategies, which use different applications and different tools, rely on the invoice data that is created in Oracle Projects. You can control the format of the invoices using invoice formats. You should consider the definition of your invoice formats as part of your invoice printing solution.

The sections below describe what an invoice format is, how to define and use invoice formats, how the Generate Draft Invoice process uses invoice formats to select and group expenditure items on an invoice line. Some sample invoice formats and the resulting invoice lines are also illustrated.

What is an invoice format?

An invoice format determines how Oracle Projects creates an invoice line for a project that is billed based on time and materials.

Defining Invoice Formats

In defining invoice formats, consider the layout of the invoice, including the header and detail regions, when printed on paper, and the different types of invoice layouts required by groups in your company or for certain types of projects.

You can define different formats for labor, non-labor, retention, and retention billing invoice lines. You can define as many invoice formats as you need for different types of projects or organizations.

When you define contract project types during implementation, you specify default invoice formats for labor and non-labor invoice lines. These invoice formats provide default values to all projects that are classified by the project type. See: Invoice Formats and Project Types.

Using Invoice Formats

When you enter a contract project, the invoice formats are defaulted from the project type that you selected for the project. You can override the default invoice formats in the Projects form using any of the formats defined during implementation.

When you generate invoices for the project, the Generate Draft Invoice process looks to the project to determine which format to use when grouping expenditure items on an invoice.

Processing Invoice Lines Using Invoice Formats

The Generate Draft Invoice process performs the following steps to create invoice lines:

Figure 1 - 6 illustrates how you can create and format invoice lines using the Generate Draft Invoice process.

Before the expenditure items are processed for billing, Generate Draft Invoice sets the job, job title, and employee billing title for all labor items for easier processing of invoice formats.

Creating and Formatting Invoice Lines

Creating and formatting invoice lines

the picture is described in the document text

Invoice Formats - Sample Invoice Lines

The invoice formats of three sample projects are listed below along with the resulting invoice lines created from the expenditure items invoiced on the project. You can study these sample invoice formats and resulting invoice lines to help you determine how to define your company's invoice formats.

This graphic lists the invoice formats of Project A. They are defined as follows:

Sample invoice lines: Project A

the picture is described in the document text

The following table describes the sample invoice line items created.

Item Type Item Description Bill Amount
Labor Carlisle , Jeff Senior Consultant 45.0 Hrs@$ 180.00 8100.00
Labor Connors , Zach Staff Consultant 12.5 Hrs@$ 100.00 1250.00
Labor Marlin , Amy Principal Consultant 20.0 Hrs@$ 200.00 4000.00
Non-Labor Computer Services 54.0 Hours 540.00
Retention 10% Retention -1389.00
  Total Amount 12501.00

This following graphic lists the invoice formats of Project B. They are defined as follows:

Sample invoice lines: Project B

the picture is described in the document text

The following table describes the sample invoice line items created.

Item Type Item Description Bill Amount
Labor Site: Pittsburgh Services Level: Principal Draftsman Hours: 16.5 3712.50
Labor Site: Pittsburgh Services Level: Staff Consultant Hours: 10.5 1417.50
Labor Site: Salt Lake City Services Level: Staff Consultant Hours: 8.5 1080.00
Labor Site: San Francisco Services Level: Senior Engineer Hours: 22.0 3850.00
Labor Site: San Francisco Services Level: Staff Consultant Hours: 13.0 1755.00
Labor Site: San Francisco Services Level: Principal Draftsman Hours: 18.0 4050.00
Non-Labor Site: Salt Lake City Computer Services PC 1.00 Hours 10.00
Non-Labor Site: San Francisco Computer Services 386 Laptop 2.00 Hours 30.00
Non-Labor Site: San Francisco Computer Services PC 8.00 Hours 80.00
Non-Labor Site: San Francisco Computer Services Sparc 6.50 Hours 325.00
  Total Amount 16310.00

Figure 1 - 9 lists the invoice formats of Project C. They are defined as follows:

Sample invoice lines: Project C

the picture is described in the document text

The following table describes the sample invoice line items created.

Item Type Item Description Bill Amount
Labor 2.0 Analysis Marlin, Ms. Amy T. 8.0 Hours at the hourly rate of $135.00 1080.00
Labor 2.0 Analysis Robinson, Mr. James A. 10.5 Hours at the hourly rate of $175.00 1837.50
Labor 3.0 Design Connors, Mr. Zach 16.5 Hours at the hourly rate of $135.00 2160.00
Labor 3.0 Design Robinson, Mr. James A. 18.0 Hours at the hourly rate of $175.00 3150.00
Non-Labor 2.0 Analysis - - Expenses 325.00
Non-Labor 3.0 Design - - Expenses 687.00
  Total Amount 9239.50

Credit Types

Oracle Projects lets you award different kinds of revenue credit to your employees, such as sales credit, marketing credit, or quota credit. You can credit one or more employees for a specific project or task.

For example, if you want to credit an employee for bringing in a contract in a market sector for which you currently have few or no projects, you can define a credit type with a name such as Diversity Credit. After you define the project, you specify the employee as a credit receiver of Diversity Credit.

Defining Credit Types

To define a credit type:

  1. Navigate to the Credit Type Lookups window.

  2. Enter the following information for the credit type.

  3. Check the Enabled check box.

  4. Save your work.

For detailed information on defining and updating lookups in Oracle Projects, see: Oracle Projects Lookups.

Fremont Corporation Credit Types

Fremont Corporation awards Marketing Credit to a marketing staff member who generates a lead. Fremont also awards Quota Credit to a staff member who brings in a project.

Fremont's credit types are shown in the following table:

Credit Type Name Description
Marketing Credit Credit for generating leads
Quota Credit Credit for acquiring a project

Related Topics

Transferring Sales Credit to Oracle Receivables

Effective Dates

Credit Types Listing, Oracle Projects Fundamentals

Event Types

Unlike labor costs or other billable expenses, a bonus your business receives for completing a project ahead of schedule is not attributable to any expenditure item.

In these cases, you use an event, rather than an expenditure item, to account for a bonus or other sum of money. An event is an entry assigned to a top task or project that generates revenue and/or billing activity, but is not directly related to any expenditure items.

You classify events by event type. When you define an event type, you assign it one of the predefined classifications. When you enter an event, its event type classification determines how the event affects revenue and billing for a particular project.

You can define as many event types as you need, but you cannot create additional classifications.

Defining Event Types

To define an event type:

  1. In the Event Types window, specify an event type, a description of the event, a revenue category, and a event type class.

  2. Optionally, click Tax Classification Code to select the default tax classification code for customer invoice lines created for the event type and operating unit.

  3. Save your work.

Event Types Window Reference

Event Type. Enter a unique, descriptive name for this event type.

Revenue Category. Enter the revenue category that you want to associate with this event type.

Class. Enter a classification for this event type to determine how an event affects the revenue and billing for a particular project. Oracle Projects provides you with the following classifications:

The following table describes how each event type classification affects revenue and billing.

Classification Revenue Effect Billing Effect
Automatic Depends on billing extension definition Depends on billing extension definition
Deferred Revenue No effect Bill for amount of event
Invoice Reduction No effect Reduce a bill by amount of event
Manual Accrue amount of event Bill for amount of event
Scheduled Payment No effect Bill for amount of event, FIFO
Write-Off Reduce by amount of event No effect
Realized Gains Increase by amount of event No effect
Realized Losses Decrease by amount of event No effect

Tax Classification Code. Optionally, click Tax Classification Code to select the tax classification code for customer invoice lines created for this event type and operating unit. Oracle Projects uses this as the default tax classification code based on the Application Tax Options hierarchy that you define in Oracle E-Business Tax for the Oracle Projects application and the project’s operating unit. For more information on setting up tax classification codes and the hierarchy of application tax options, see the Oracle E-Business Tax User Guide.

Fremont Corporation Event Types

Fremont Corporation uses all of the event type classifications to account for a number of situations. Fremont assumes most event revenue is from labor, and they want to track revenue from these event types as variations to labor revenue: Cost-to-Cost revenue, Bonus, and Write-Off.

The following table shows Fremont's event types:

Event Type Name Description Classification Revenue Category
Bonus Performance bonus Write-On Labor
Cost-to-Cost Revenue Cost-to-cost revenue Automatic Labor
Fee Fee earned Automatic Fee
Invoice Reduction Invoice reduction Invoice Reduction Payment
Manual Manual event Manual Fee
Milestone Progress payment Scheduled Payment Payment
Payment Scheduled payment Scheduled Payment Payment
Prebill Advance payment Deferred Revenue Payment
Retainer Retainer payment Deferred Revenue Payment
Surcharge Surcharge Automatic Fee
Write-Off Unearned revenue Write-Off Labor

Assigning Event Types for Cost-to-Cost Revenue

If your company uses the cost-to-cost billing method (denoted by a distribution rule of COST), you need to assign a default event type to the predefined billing extensions of Cost-to-Cost Revenue and Cost-to-Cost Invoice. Oracle Projects automatically calls and executes two predefined billing extensions for cost-to-cost revenue accrual and invoicing methods. Oracle Projects creates automatic events for the revenue and invoice amounts.

Prerequisites

To Assign Event Types For Cost-to-Cost Revenue:

  1. In the Billing Extensions window, query the two billing extensions and assign an event type to the Default Event Type field.

  2. Save your work.

Assigning Budget Types

You can change the cost and revenue budget types used as input for this extension. For example, you can use the forecast cost budget instead of the approved cost budgets. To make this change, change the cost budget type and revenue budget type on the predefined billing extension.

Fremont Corporation Event Type for Cost-to-Cost Revenue

Fremont Corporation assigns the Cost-to-Cost Revenue automatic event type to the two predefined billing extensions, Cost-to-Cost Revenue and Cost-to-Cost Invoice.

Related Topics

Event Types Listing, Oracle Projects Fundamentals

Automatic Events, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference

Overview of Billing Extensions, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference

Defining and Assigning Billing Assignments

You use billing assignments to select billing extensions for revenue accrual or invoicing, or both.

You can create billing assignments for a project type, or for a project at the project or top task level.

Related Topics

Project Types

Project Definition and Information, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference

Define Percent Complete Revenue and Invoicing

To generate revenue or draft invoices using percent complete, you must complete the following steps:

  1. Billing Extension:

    You must create two event types with the event class automatic (one for revenue and one for invoicing), and associate each with one of the following predefined billing extensions, depending on whether you are generating revenue or invoices:

  2. Project Setup:

    The revenue distribution rule for the project must be one of the following rules:

    In addition, you must enter percent complete at the funding level.

    The billing extensions are predefined to be assigned to the project (Project Specific attribute = Yes). If you want to assign an extension to the project type, you can make a copy of the predefined extension and then change the Project Specific attribute to No. You then assign the extension to the appropriate project types. You may also want to deactivate the predefined extensions by setting the end date.

Cost Accrual Calculation using Billing Extensions

Oracle Projects provides an example billing extension in which the cost accrual amounts are calculated. This example is called the Cost Accrual Billing Extension.

Revenue-Based Cost Accrual Formula: Example

The following formula shows the calculation used in the example billing extension:

Cost Accrual Amount = (AR/BR * BC) - CS
Where:
AR = Accrued revenue to date
BR = Budgeted revenue
BC = Budgeted costs
CS = Accrued costs to date

Designing a Cost Accrual Billing Extension

You must decide some of the inputs to this extension:

Following are some facts to consider when you are using the example cost accrual billing extension.

Implementing the Cost Accrual Example

In this section, we describe the setup steps required to support the Cost Accrual Billing Extension example. We also show some examples of a cost accrual setup.

1. Define Event Types

Define event types with the classification Automatic. You need an event type for events that will account for each of the following accounts:

You will drive AutoAccounting rules based on these event types.

The following table shows sample cost accrual event types:

Event Type Description Class
Cost Accrual Cost Accrual Account Automatic
Cost Accrual Contra Cost Accrual Contra Account Automatic
Cost WIP Cost WIP Account (for reversing entries) Automatic

2. Define the cost accrual billing extension.

To define the cost accrual billing extension:

a) Value Sets and Descriptive Flexfields for Billing Extension

Set up the value sets and descriptive flexfield used in the billing extension definition. The Cost Accrual Billing Extension example requires following five descriptive flexfield segments to be set up on the Billing Extension:

The three segments that hold event types should use a table-validated value set with a length of 30 characters which displays all automatic event types using the following SQL:

where event_type_classification = 'AUTOMATIC'

Note: After you have defined and used the billing extension, you must not change the values of the descriptive flexfield.

b) Define the Billing Extension

You define the billing extension with the following key attributes:

Fremont Corporation Cost Accrual Implementation

Fremont Corporation implements cost accrual as shown below:

You must install the billing extension PL/SQL package. For details, see Billing Extensions, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

See: Implementing Your Own Cost Accrual Procedures and Extensions.

3. Assign Billing Extension to Project Types

Assign the billing extension to the appropriate project types.

You can also choose to implement a billing extension that you assign to specific projects. To do this, you enable the Project Specific check box in the Billing Extension window. However, for the cost accrual example, you are expected to assign the billing extension at the project type level.

See: Defining Billing Extensions, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference and Project Types.

4. Define AutoAccounting

Define AutoAccounting setup for cost WIP and cost accruals. Typically, you define GL accounts for each of the different buckets, as shown in the table below:

Account Name Account Number
Cost WIP 1280
Cost Accrual 128
Cost Accrual Contra 1286

To define AutoAccounting for Cost WIP and Cost Accruals:

a) Cost WIP Account for Incurring Costs (Via Expenditure Items)

To account for actual raw costs in cost WIP, you must perform the following steps:

For more information about burdened costs, see: Burdening (Cost Plus Processing) and Accounting for Total Burdened Costs, Oracle Project Costing User Guide.

b) Cost Accrual Accounts for Events Resulting from the Billing Extension

Assign the AutoAccounting rules to the Event Revenue function under the Write-On function transaction (under which Automatic events are accounted). To account for different event types under one function transaction, you must define a rule based on the event types. The rule may be a parameter-based rule that uses a lookup set, or it can be a SQL statement AutoAccounting rule that uses the SQL statement to map the event type to the account value.

Note: The AutoAccounting rules for the Cost WIP reversing entries created via an event should result in the same accounts as the AutoAccounting rules used to derive the Cost WIP account for costs incurred via expenditure items.

You can optionally set up Oracle Subledger Accounting to overwrite the default accounts, or individual segments of the accounts, that Oracle Projects derives using AutoAccounting rules. For additional information, see: Subledger Accounting for Revenue and Billing.

Note: The account derivation rules in Oracle Subledger Accounting for the Cost WIP reversing entries created via an event should result in the same accounts as the account derivation rules used to derive the Cost WIP account for costs incurred via expenditure items.

5. Implement Project Verification Rules

Implement project verification rules to ensure that project closing entries are made before the project status is changed to Closed. The rules should ensure that the closing entries are made when the project has a project status with a system status of Pending Close.

Oracle Projects provides an example of how to enforce this requirement in the project verification extension. To implement the requirement, you remove the comments around the section for cost accruals in the project verification extension.

See: Project Verification Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

6. Implement Cost Accrual Columns in Project Status Inquiry

Implement columns to view Cost WIP and Cost Accrual amounts in the Project Status Inquiry window.

The PSI client extension includes an example of how to implement the following columns in columns 28 through 33 in the Project Status Inquiry window:

To implement these columns, you perform the following steps:

  1. Remove the comments around the section for cost accruals in the project status inquiry column extensions. See: PSI Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

  2. Define the Project Status Inquiry columns listed above, and regenerate the view in the Project Status Inquiry Columns window. See: Project Status Inquiry Setup.

When a project is closed, these columns are updated. At that point, the amounts for the PTD (period to date) columns are a combination of PTD activity and closing activities.

7. Implement the Cost Accrual Identification Extension in Intercompany Billing

The Cost Accrual Identification extension includes sample code that calls the cost accrual identification procedure in the sample Cost Accrual Billing extension. If you are using the predefined Cost Accrual Billing extension, enable the sample code in the Cost Accrual Identification extension by removing the comment marks. The default logic in this extension returns a value of No for cost accrual projects. See: Cost Accrual Identification Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

Implementing Your Own Cost Accrual Procedures and Extensions

Your business requirements for cost accruals may be different from those addressed in the cost accrual example that Oracle Projects provides. If this is the case, you must design and create your own billing extension and appropriate setup data to match your requirements.

Listed below are some of the business requirements for cost accruals that may vary in your company from the cost accrual example provided by Oracle Projects:

Oracle Projects provides a client extension that you use as the basis of your cost accrual extension procedures. For information about the Cost Accrual Extension, see: Cost Accrual Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

Profile Options and Client Extensions for Revenue and Invoicing

Following are the profile options and client extensions you set to implement revenue and invoicing.

Profile Options for Revenue and Invoicing

Set the following profile options to control processing for revenue and invoicing.

See: Profile Options in Oracle Projects.

Client Extensions for Revenue and Invoicing

You can optionally implement the following client extensions to extend the revenue and billing functionality:

See: Client Extensions, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

Setting Up for Agreements and Funding

The following instructions give details about the Agreements and Funding steps in the Oracle Project Billing Product Implementation Checklist.

Defining Agreement Types

Agreement types categorize the various kinds of agreements you negotiate with clients. For example, you can define one agreement type for all verbal agreements and another for all agreements using purchase orders. You might also define additional agreement types to distinguish internal agreements from those with your external customers.

If you define an agreement type and limit revenue and or invoice, any project funded by that agreement type stops accruing revenue and generating invoices when it reaches the revenue and or invoice limit. If you define an agreement type and do not limit revenue and invoice, any project funded by that agreement type issues a warning when the revenue and invoice limit is exceeded, but does not stop accruing revenue or generating invoices. This is referred to as a hard limit or a soft limit.

Prerequisites

To define an agreement type:

  1. In the Agreement Types window, enter a Name and Description of the agreement type you want to define.

    If you want payment terms to default when you enter an agreement with this agreement type, enter the Default Terms.

    Enable the Default Revenue/Invoice Limit option if you want the Hard Limit option of the Agreements widow to be enabled by default when you enter an agreement with this agreement type.

  2. Save your work.

Fremont Corporation Agreement Types

Fremont Corporation enforces revenue/invoice limits on purchase orders and change orders, since these types of agreements always cover specific work. The retainer letter and service agreement types are defined with a disabled Revenue/Invoice Limit option, since the exact amount of these kinds of agreements is usually not known immediately. The terms default for all agreements is net payment within 30 days of receiving the invoice.

Fremont's agreement types are shown in the following table:

Name Description Terms Default Revenue / Invoice Limit Default
Purchase Order Customer Purchase Order 30 Net Enabled
Change Order Change to a Purchase Order 30 Net Enabled
Retainer Letter Retainer Letter 30 Net Disabled
Service Agreement Service Agreement 30 Net Disabled
Verbal Agreement Non-Written Agreement 30 Net Disabled

Related Topics

Agreement Types Listing, Oracle Projects Fundamentals

Defining Agreement Templates

Agreement templates make it faster for you to create an agreement for your project. You can create quick agreement projects (projects associated with an agreement template) for rapid project and agreement setup. For details about quick agreement projects, see Quick Agreement / Funding Projects, Oracle Project Billing User Guide.

To define an agreement template:

  1. Navigate to the Agreement Template window.

  2. Enter the same information you enter for an agreement:

  3. Save your work.

Agreement templates can only be viewed in the Agreement Template Entry window. You cannot view agreement templates in the Agreement Entry window.

Defining Receivables Prepayment Activities

If you plan to set up agreements that require or permit prepayments, you must enter one receivables activity for prepayments for each operating unit in which you will use this capability. You enter receivables activities in Oracle Receivables setup.

Related Topics

Receivables Activities, Oracle Receivables Implementation Guide

Client Extensions for Agreements and Funding

To extend the use of agreements and funding for your business, you can implement the Funding Revaluation Factor client extension.

To determine whether to set the Advance Required flag for agreements to Yes or No automatically, you can implement the Advance Required client extension.

See: Client Extensions, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

Related Topics

Entering Agreements, Oracle Project Billing User Guide

Agreement Template, Oracle Project Billing User Guide

Customers

The following instructions give details about the Customers steps in the Oracle Project Billing Product Implementation Checklist.

You define customers in either the Customers or Customer Summary window. Customers can be defined either in Oracle Receivables or in Oracle Projects. See: Entering and Updating Customer Information, Oracle Receivables User's Guide.

Note: You must define the option for customer numbering when you implement Oracle Projects, whether or not you have also installed Oracle Receivables. If you have both Oracle Projects and Oracle Receivables installed, you enter the Oracle Receivables system options related to customers in the Oracle Projects System Options window.

In Oracle Projects, you use customers, customer addresses, and customer contacts to specify customers for which you are doing project work. Each customer for a contract project must have one primary bill-to address, one primary ship-to address, and one primary bill-to contact. The primary bill-to contact must be entered in the Primary Bill-To Contacts Role window and in the Business Purpose Details window.

Note: A bill-to address is not required for customers that have a 0% contribution. For customers that have a contribution percentage greater than 0%, a bill-to address is required to generate invoices for a project. Bill-to and ship-to addresses are optional for customers assigned to capital projects or indirect projects."

When using the inter-project billing or intercompany billing features, you must define a customer bill and ship site for each internal organization to which the current organization provides resources. A receivables invoice will be created in the current organization's Receivables subledger to recover costs for resources provided to these internal customers.

Note: In a multiple organization environment, customers are shared across operating units. However, you must define customer addresses for each operating unit. If multiple operating units are doing project work with the same customer, each operating unit must have an address defined for the customer.

Fremont Corporation Customers

Fremont Corporation's accounting department needs to add three customers to their customer database. Fremont uses the Quick Customer Entry form to define customers. Since each customer has only one address, the addresses are set up as the primary bill-to and ship-to sites. Each bill-to contact is identified as the primary bill-to contact since there is only one contact for each customer.

Fremont's new customers are shown below:

Note: The Bay Group has different bill to and ship to addresses.

Variable Description
City of San Francisco Customer Number: 1000
Bill To Address: City Hall, San Francisco, CA 94112, U.S.
Bill: Yes
Ship: Yes
Market: Yes
Port of Oakland Customer Number: 1001
Bill To Address: 10 E. Seaside, Oakland, CA 94130, U.S.
Bill: Yes
Ship: Yes
The Bay Group Customer Number: 1004
Bill To Address: 120 Spear Street, San Francisco, CA 94120, U.S.
Bill: Yes
Ship: Yes
Market: Yes
Ship To Address: Hunter's Point, South San Francisco, CA 91468, U.S.
Bill: Yes
Ship: Yes
Market: Yes

The following table shows the Address Contacts for Fremont's new customers:

Customer Name Contact Last Name First Title Job Title Bill Ship
City of San Francisco Lasky John Mr. AP Supervisor Yes Yes
Port of Oakland Winston Ed Mr. AP Supervisor Yes Yes
The Bay Group (Bill to Address contact) Davies J. Mr. AP Supervisor Yes No

Accounting for Revenue and Billing

The following instructions give details about the Accounting for Revenue and Billing steps in the Oracle Project Billing Product Implementation Checklist. The instructions are divided into two sections. The first section discusses how to set up accounting for project revenue and billing in Oracle Subledger Accounting. The second section discusses how to set up AutoAccounting for project revenue and billing in Oracle Projects.

Subledger Accounting for Revenue and Billing

Oracle Subledger Accounting is an intermediate step in the accounting flow between subledger applications, such as Oracle Projects and Oracle Receivables, and Oracle General Ledger.

For revenue, Oracle Projects uses AutoAccounting to create default revenue accounts that it sends to Oracle Subledger Accounting. Oracle Projects provides predefined setup in Oracle Subledger Accounting to accept the default revenue accounts from Oracle Projects and transfer them to Oracle General Ledger without change. You can optionally define your own detailed project revenue accounting rules in Oracle Subledger Accounting to overwrite the default revenue accounts from Oracle Projects. You can set up rules in Oracle Subledger Accounting to overwrite individual account segments, instead of the entire Accounting Flexfield.

For information on the setup that Oracle Projects predefines in Oracle Subledger Accounting, see: Integrating with Oracle Subledger Accounting, Oracle Projects Fundamentals.

For billing, Oracle Projects interfaces the accounting that it creates using AutoAccounting to Oracle Receivables along with the associated customer invoice. In turn, Oracle Receivables creates accounting in Oracle Subledger Accounting. You can set up your own Oracle Receivables rules in Oracle Subledger Accounting to overwrite the accounts.

Note: To define your own setup in Oracle Subledger Accounting, you must copy the predefined data and make changes to the copy. You cannot directly modify the predefined data that Oracle Projects provides in Oracle Subledger Accounting.

Related Topics

AutoAccounting and Subledger Accounting

Understanding Subledger Accounting Setup for Oracle Projects, Oracle Projects Fundamentals

Accounting Methods Builder, Oracle Subledger Accounting Implementation Guide

Accounting for Receivables, Oracle Receivables User's Guide

Custom Sources

In the Subledger Accounting for Costs section, see: Custom Sources.

Journal Line Types

A journal line type determines the characteristics of subledger journal entry lines. These characteristics include whether the line is used to create actual, budget, or encumbrance entries, whether matching lines are merged, and whether data is transferred to the general ledger in summary or detail form. You can optionally set up your own journal line types.

You set up journal line types for a particular event class. Event classes represent the actions possible for a particular transaction type or document. For additional information, in the Subledger Accounting for Costs section, see: Journal Line Types.

Oracle Projects provides a separate AutoAccounting function for each type of project revenue. Oracle Projects predefines only one event class for revenue for Oracle Subledger Accounting. Oracle Projects predefines a set of journal line types in Oracle Subledger Accounting for the Revenue event class to enable you to define rules for each type of project revenue. The following table shows the mapping between predefined journal line types for the Revenue event class in Oracle Subledger Accounting and revenue AutoAccounting functions and function transactions in Oracle Projects.

Journal Line Type AutoAccounting Function AutoAccounting Function Transaction
Burden Cost Revenue Burden Cost Revenue Account All function transactions for the Burden Cost Revenue Account function
Event Revenue Event Revenue Account Revenue Write-On Events
Event Write-Off Revenue Event Revenue Account Revenue Write-Off Events
Expense Report Revenue Expense Report Revenue Account All function transactions for the Expense Report Revenue Account function
Inventory Revenue Inventory Revenue Account All function transactions for the Inventory Revenue Account function
Labor Revenue Labor Revenue Account All function transactions for the Labor Revenue Account function
Miscellaneous Transaction Revenue Misc Trans Revenue Account All function transactions for the Misc Trans Revenue Account function
Supplier Invoice Revenue Supplier Invoice Revenue Acct All function transactions for the Supplier Invoice Revenue Acct function
Unbilled Receivable Revenue and Invoice Accounts Unbilled Receivable Account
Unearned Revenue Revenue and Invoice Accounts Unearned Revenue Account
Realized Gains Revenue and Invoice Accounts Realized Gains Account
Realized Losses Revenue and Invoice Accounts Realized Losses Account
Usage Revenue Usage Revenue Account All function transactions for the Usage Revenue Account function
WIP Revenue WIP Revenue Account All function transactions for the WIP Revenue Account function

Oracle Projects also predefines a set of journal line types for revenue adjustment accounting. For additional information, see: Integrating with Oracle Subledger Accounting, Oracle Projects Fundamentals.

Journal Entry Descriptions

In the Subledger Accounting for Costs section, see: Journal Entry Descriptions.

Mapping Sets

In the Subledger Accounting for Costs section, see: Mapping Sets.

Account Derivation Rules

In the Subledger Accounting for Costs section, see: Account Derivation Rules.

Journal Lines Definitions

In the Subledger Accounting for Costs section, see: Journal Lines Definitions.

Application Accounting Definitions

In the Subledger Accounting for Costs section, see: Application Accounting Definitions.

Subledger Accounting Methods

In the Subledger Accounting for Costs section, see: Subledger Accounting Methods .

Assign Application Accounting Definitions to a Subledger Accounting Method

In the Subledger Accounting for Costs section, see: Assign Application Accounting Definitions to a Subledger Accounting Method .

Assign a Subledger Accounting Method to a Ledger

In the Subledger Accounting for Costs section, see: Assign a Subledger Accounting Method to a Ledger.

Post-Accounting Program Assignments

In the Subledger Accounting for Costs section, see: Post-Accounting Program Assignments.

AutoAccounting for Revenue and Billing

Oracle Projects uses AutoAccounting to generate accounting for revenue and billing transactions. When you implement AutoAccounting, you define rules that determine accounts that Oracle Projects assigns to transactions to meet your business requirements. Oracle Projects uses the rules you define whenever it creates accounting for revenue and billing transactions.

For revenue accounting, Oracle Projects generates revenue accounting events for Oracle Subledger Accounting. The process PRC: Create Accounting creates the draft or final accounting for the accounting events. Oracle Projects predefines setup in Oracle Subledger Accounting so that the create accounting process accepts the default accounts that Oracle Projects derives using AutoAccounting without change. Oracle Subledger Accounting transfers the final accounting to Oracle General Ledger.

You can optionally define your detailed accounting rules in Oracle Subledger Accounting. In this case, the create accounting process uses the rules you define in Oracle Subledger Accounting to overwrite the default accounts, or individual account segment values, that Oracle Projects derives using AutoAccounting.

If you set up your own rules in Oracle Subledger Accounting, you must still set up AutoAccounting so that Oracle Projects can determine valid default accounts. The AutoAccounting setup enables processes, such as processes that generate revenue and generate revenue accounting events, to determine the default accounts that Oracle Projects sends to Oracle Subledger Accounting.

For billing, Oracle Projects interfaces the accounting that it creates using AutoAccounting to Oracle Receivables along with the associated customer invoice. In turn, Oracle Receivables creates accounting in Oracle Subledger Accounting.

Related Topics

Subledger Accounting for Revenue and Billing

Oracle Subledger Accounting Implementation Guide

Set Profile Option: Selective Flexfield Segment for AutoAccounting

For optimum performance, it is recommended that you set this profile option. The speed of distribution processes can be dramatically affected by the value of this profile option.

For more details, see: PA: Selective Flexfield Segment for AutoAccounting.

Accounting for Labor Revenue

Oracle Projects uses the Labor Revenue Account function to determine default revenue accounting for labor items. The resulting labor revenue is generally awarded to either a project-managing organization, or an employee's owning organization; this labor revenue does not include borrowed and lent labor revenue.

Labor Revenue Account Function

When you run the process PRC: Generate Draft Revenue, Oracle Projects uses the Labor Revenue Account transactions to credit a default revenue account for labor items.

The Labor Revenue Account function consists of the following transactions:

If you do not distinguish labor revenue between private and public projects, then you only need to enable the All Labor Revenue transaction.

Fremont Corporation Labor Revenue Account Function

Fremont Corporation always awards labor revenue to the employee's owning organization even if the employee worked on a project owned by a different organization. When applicable, Fremont awards labor revenue to the project-managing organization using borrowed and lent revenue accounts.

Fremont uses revenue credited to the project-managing organization for reporting purposes only.

Fremont enables the Private Labor Revenue and Public Labor Revenue transactions to distinguish revenue earned between private and public projects.

Fremont Corporation uses two accounts to record labor revenue:

Define Rules to Determine Segment Values:

To implement the Labor Revenue Account function, Fremont defines two rules:

Fremont uses one rule in the Private Labor Revenue transaction and one rule in the Public Labor Revenue transaction.

The following table shows the new AutoAccounting rules that Fremont Corporation defines to derive account segments:

Name of Rule Description Intermediate Value Source Parameter Name or Constant Value Segment Value Source Lookup Set
Private Fee Revenue Private Professional Fee Revenue Constant 4100 Intermediate Value NA
Public Fee Revenue Public Professional Fee Revenue Constant 4101 Intermediate Value NA

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield for both transactions.

Enable Transactions and Assign Rules:

Fremont enables the transactions shown in the following table:

Function Name Transaction Name
Labor Revenue Account Private Labor Revenue
Labor Revenue Account Public Labor Revenue

The segment rule pairings for these transactions are shown in the following table:

Transaction Name Segment Number Segment Name Rule Name
Private Labor Revenue 0 Company Employee Company
Private Labor Revenue 1 Cost Center Employee Cost Center
Private Labor Revenue 2 Account Private Fee Revenue
Public Labor Revenue 0 Company Employee Company
Public Labor Revenue 1 Cost Center Employee Cost Center
Public Labor Revenue 2 Account Public Fee Revenue

Accounting for Expense Report Revenue

Oracle Projects uses the Expense Report Revenue Account function to determine default revenue accounting for expense report items.

Expense Report Revenue Account Function

When you run the process PRC: Generate Draft Revenue, Oracle Projects uses the Expense Report Revenue Account transactions to credit a default revenue account for expense report items.

The Expense Report Revenue Account function consists of the following transactions:

If you do not distinguish expense report revenue between private and public projects, then you only need to enable the All Expense Report Revenue transaction.

Fremont Corporation Expense Report Revenue Account Function

Expense Report revenue is posted to the project-managing organization's Expense Report Revenue account. Since Fremont does not differentiate between public and private projects when it calculates expense report revenue, it enables only the All Expense Report Revenue transaction.

Fremont Corporation uses one revenue account to record expense report revenue:

Define a Rule to Determine Account Segment Value:

To implement the Expense Report Revenue Account function, Fremont defines a rule to supply the Expense Report Revenue account code for the Account segment of its Accounting Flexfield. The Expense Report Revenue account is always 4300 since Fremont's chart of accounts uses only one account.

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the All Expense Report Revenue Transaction and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Project Company
1 Cost Center Project Cost Center
2 Account Expense Report Revenue

Accounting for Usage Revenue

Generating usage revenue is very similar to generating labor revenue. Oracle Projects generates usage revenue and, if you like, borrowed and lent usage revenue.

Oracle Projects uses the Usage Revenue Account function to determine default revenue accounting for non-labor items. Usage revenue is awarded to either a project-managing organization, or a non-labor resource's owning organization; this usage revenue does not include borrowed and lent labor revenue.

The Usage Revenue Borrowed Account and Usage Revenue Lent Account functions allow you to record revenue in both a project-managing organization and in a non-labor resource's owning organization (when these two organizations are different).

The organization to which you award revenue (using the Usage Revenue Account function) becomes the lending organization; Oracle Projects uses the Usage Revenue Lent Account transactions to debit a default revenue account of the lending organization.

The organization to which you do not award revenue (using the Usage Revenue Account function) becomes the borrowing organization; Oracle Projects uses the usage Revenue Borrowed Account transactions to credit a default revenue account of the borrowing organization

When you run the PRC: Generate Draft Revenue process, Oracle Projects compares the project-managing organization and the non-labor resource's owning organization to determine whether to use the Usage Revenue Borrowed Account and Usage Revenue Lent Account functions when it determines default revenue accounting for non-labor items.

If the project-managing organization is the same as the non-labor resource's owning organization, Oracle Projects uses only the Usage Revenue Account function to credit a default revenue account; the Usage Revenue Borrowed Account and Usage Revenue Lent Account functions are not necessary.

If the project-managing organization is not the same as the non-labor resource's owning organization, Oracle Projects first ensures that you have enabled the Usage Revenue Borrowed Account and Usage Revenue Lent Account functions, and then uses them to create default revenue credit and debit entries for borrowed and lent usage revenue. The borrowed and lent entries are in addition to the usage revenue credits Oracle Projects creates using the Usage Revenue Account transactions. If you do not want to record borrowed and lent usage revenue entries, then do not implement the Usage Revenue Borrowed Account and Usage Revenue Lent Account functions.

The Usage Revenue Borrowed Account and Usage Revenue Lent Account functions are distinct from the Usage Revenue Account function to allow you to separate borrowed and lent usage revenue into as many different accounts as you separate usage revenue.

Usage Revenue Account Function

When you run the process PRC: Generate Draft Revenue, Oracle Projects uses the Usage Revenue Account transactions to determine default revenue accounting for usage items.

The Usage Revenue Account function consists of the following transactions:

If you do not distinguish usage revenue between private and public projects, then you only need to enable the All Usage Revenue transaction.

Fremont Corporation Usage Revenue Account Function

Fremont always awards usage revenue to the resource-owning organization, and awards usage revenue to the project-managing organization using borrowed and lent revenue accounts. Since Fremont does not distinguish revenue earned between private and public projects, it enables just the All Usage Revenue transaction.

Fremont Corporation uses three revenue accounts to record usage revenue, depending upon the expenditure type:

Define a Lookup Set:

Fremont defines a lookup set to map expenditure types to the appropriate revenue account.

Fremont defines the lookup set shown in the following table:

Lookup Set Name Description
Usage to Revenue Map the expenditure type for usage items to the appropriate revenue account

Segment Value Lookups for the Usage to Revenue Lookup Set:

The segment value lookups for the Organization to Division lookup set are shown in the following table:

Intermediate Value (Expenditure Type) Segment Value (Account Code)
Computer Services 4200
Vehicle 4201
Field Equipment 4201
Other Asset 4202

Define a Rule to Determine Account Segment Value:

To implement the Usage Revenue Account function, Fremont defines a rule to determine the revenue account for usage revenue. Fremont uses the lookup set Usage to Revenue to define the revenue account rule.

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the All Usage Revenue Transaction and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Resource Company
1 Cost Center Resource Cost Center
2 Account Usage Revenue

Accounting for Miscellaneous Revenue

Oracle Projects uses the Misc Trans Revenue Account function to determine default revenue accounting for miscellaneous transaction items.

Misc Trans Revenue Account Function

When you run the process PRC: Generate Draft Revenue, Oracle Projects uses the Misc Trans Revenue Account transactions to determine default revenue accounting for miscellaneous transaction items.

The Misc Trans Revenue Account function consists of the following transactions:

If you do not distinguish miscellaneous transaction revenue between private and public projects, then you only need to enable the All Misc Trans Revenue transaction.

Accounting for Burden Transaction Revenue

Oracle Projects uses the Burden Cost Revenue Account function to determine default revenue accounting for burden transaction items.

Burden Cost Revenue Account Function

When you run the process PRC: Generate Draft Revenue, Oracle Projects uses the Burden Cost Revenue Account transactions to credit a default revenue account for burden transaction items.

The Burden Cost Revenue Account function consists of the following transactions:

If you do not distinguish burden revenue between private and public projects, then you only need to enable the All Burden Txn Revenue transaction.

Accounting for Inventory Revenue

Oracle Projects uses the Inventory Revenue Account function to determine default revenue accounting for inventory items.

Inventory Revenue Account Function

When you run the process PRC: Generate Draft Revenue, Oracle Projects uses the Inventory Revenue Account transactions to credit a default revenue account for inventory items.

The Inventory Revenue Account function consists of the following transactions:

If you do not distinguish inventory revenue between private and public projects, then you only need to enable the All Inventory Revenue transaction.

Accounting for Work in Progress Revenue

Oracle Projects uses the WIP Revenue Account function to determine default revenue accounting for work in process (WIP) items.

WIP Revenue Account Function

When you run the process PRC: Generate Draft Revenue, Oracle Projects uses the WIP Revenue Account transactions to credit a default revenue account for work in process items.

The WIP Revenue Account function consists of the following transactions:

If you do not distinguish work in process revenue between private and public projects, then you only need to enable the All WIP Revenue transaction.

Accounting for Supplier Cost Revenue

Oracle Projects uses the Supplier Invoice Revenue Account function to determine default revenue accounting for supplier cost items.

Supplier Invoice Revenue Account Function

When you run the PRC: Generate Draft Revenue process, Oracle Projects uses the Supplier Invoice Revenue Account transactions to credit a default revenue account for supplier cost items.

The Supplier Invoice Revenue Account function consists of the following transactions:

If you do not distinguish supplier cost revenue between private and public projects, then you only need to enable the All Invoice Revenue transaction.

Fremont Corporation Supplier Invoice Revenue Account Function

Fremont enables only the All Invoice Revenue transaction since it does not separate revenue earned between private and public projects.

Fremont Corporation uses one revenue account to record supplier cost revenue:

Define a Rule to Determine Account Segment Value:

To implement the Supplier Invoice Revenue Account function, Fremont defines a rule to supply the Subcontractor Revenue account code for the Account segment of its Accounting segment.

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the All Invoice Revenue Transaction and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Project Company
1 Cost Center Project Cost Center
2 Account Subcontractor Revenue

Accounting for Event Revenue

Expenditure items are not the only source from which you earn revenue. You create events to write-on bonus revenue, or write-off uncollectible revenue. When you run the PRC: Generate Draft Revenue process, Oracle Projects credits a default revenue account for event types with the Write-On, Manual, Realized Gains or Automatic classifications, or debits a default expense account for event types with the Write-Off or Realized Losses classification. Although there are other event type classifications, they do not affect revenue.

Event Revenue Account Function

Depending upon the classification of an event type, Oracle Projects uses the Event Revenue Account transactions to determine default revenue accounting credits for write-ons, or expense debits for write-offs.

The Event Revenue Account function consists of the following transactions:

Fremont Corporation Event Revenue Account Function

Fremont Corporation posts both write-offs and bonus revenue to the project-managing organization.

Fremont uses one expense account to record write-offs and one revenue account to record write-ons:

Define Rules to Determine Account Segment Value:

To implement the Event Revenue Account function, Fremont defines two rules:

The following table shows the new AutoAccounting rules that Fremont Corporation defines to derive the account segment value:

Name of Rule Description Intermediate Value Source Parameter Name or Constant Value Segment Value Source Lookup Set
Write-Off Revenue write-off expense account Constant 5500 Intermediate Value NA
Bonus Performance and other bonus revenue account Constant 4500 Intermediate Value NA

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable Transactions and Assign Rules:

Fremont enables the transactions shown in the following table:

Function Name Transaction Name
Event Revenue Account Revenue Write-Off Event
Event Revenue Account Write-On

The segment rule pairings for these transactions are shown in the following table:

Transaction Name Segment Number Segment Name Rule Name
Revenue Write-Off Event 0 Company Project Company
Revenue Write-Off Event 1 Cost Center Project Cost Center
Revenue Write-Off Event 2 Account Write-Off
Write-On 0 Company Project Company
Write-On 1 Cost Center Project Cost Center
Write-On 2 Account Bonus

Accounting for Unbilled Receivables, Unearned Revenue, and Receivables

To define AutoAccounting for unbilled receivables, unearned revenue, and receivables, use the transactions described below.

Revenue and Invoice Accounts Function

When you run the process PRC: Generate Revenue Accounting Events and the process PRC: Interface Invoices to Receivables, Oracle Projects uses the Revenue and Invoice Accounts function to determine which default accounts to use when it interfaces draft revenue and draft invoices.

Fremont Corporation Revenue and Invoices Account Function

Fremont Corporation assigns draft revenue and invoices to the project-managing organization when it processes revenue or invoices. Since each organization at Fremont has five separate accounts for unbilled receivables, accounts receivable, unearned revenue, write-offs, and unbilled retention, implementing each Revenue and Invoice Accounts transaction is straightforward.

Unbilled Receivables Account Transaction

When you run the process PRC: Generate Revenue Accounting Events, Oracle Projects may debit a default asset account (usually an unbilled receivables account). This transaction balances the various default revenue accounts that Oracle Projects credits when you run the PRC: Generate Draft Revenue process.

Fremont Corporation Unbilled Receivables Account Transaction

Fremont corporation uses one asset account to record unbilled receivables:

Define a Rule to Determine Account Segment Value:

To implement the Unbilled Receivables transaction, Fremont defines a rule to supply the Unbilled Receivables account code for the Account segment of its Accounting Flexfield.

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the Unbilled Receivables Transaction and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Project Company
1 Cost Center Project Cost Center
2 Account Unbilled Receivables

Accounts Receivable Transaction

When you run the PRC: Interface Invoices to Receivables process, Oracle Projects may debit a default asset account (usually an accounts receivable account). This transaction is balanced by a credit to the default unbilled receivables asset account or the default unearned revenue liability account, based on the revenue and invoice balances of the project.

Fremont Corporation Accounts Receivable Transaction

Fremont Corporation uses one asset account to record accounts receivable:

Define a Rule to Determine Account Segment Value:

To implement the Accounts Receivable transaction, Fremont defines a rule to supply the Accounts Receivable account code for the Account segment of its Accounting Flexfield.

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the Accounts Receivable Transaction and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Project Company
1 Cost Center Project Cost Center
2 Account Accounts Receivable

Unearned Revenue Account Transaction

When you bill a client for an invoice amount that is greater than the revenue accrued for the project, Oracle Projects uses the Unearned Revenue Account transaction.

When you run the process PRC: Interface Invoices to Receivables, Oracle Projects may credit a default liability account (usually an unearned revenue account). This transaction balances the default receivables asset account that Oracle Projects credits.

Fremont Corporation Unearned Revenue Account Transaction

Fremont Corporation uses one liability account to record unearned revenue:

Define a Rule to Determine Account Segment Value:

To implement the Unearned Revenue transaction, Fremont defines a rule to supply the Unearned Revenue account code for the Account segment of its Accounting Flexfield.

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the Unearned Revenue Transaction and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Project Company
1 Cost Center Project Cost Center
2 Account Unearned Revenue

Related Topics

Generate Revenue Accounting Events, Oracle Projects Fundamentals

Interface Invoices to Receivables, Oracle Projects Fundamentals

Realized Gains Account

If your funding revaluation process is enabled to include gains and losses, Oracle Projects uses the Realized Gains Account transaction to derive the default accounting for the gains account. The process PRC: Revaluate Funding for a Single Project or PRC: Revaluate Funding for a Range of Projects calculates gains and losses. If the process calculates a gain, then it creates a Realized Gain billing event to increase the project revenue.

When you run the process PRC: Generate Draft Revenue, it uses the Event Revenue function to derive a default credit account.

When you run the process PRC: Generate Revenue Accounting Events, it uses the Realized Gains Account transaction to derive a default debit account.

Fremont Corporation Realized Gains Account

Fremont Corporation uses one income account to record realized gains:

Define a Rule to Determine Account Segment Value:

To implement the Realized Gains transaction, Fremont defines a rule to supply the Realized Gains account code for the Account segment of its Accounting Flexfield.

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the Realized Gains Account and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Project Company
1 Cost Center Project Cost Center
2 Account Realized Gains

Related Topics

Generate Revenue Accounting Events, Oracle Projects Fundamentals

Realized Losses Account

If your funding revaluation process is enabled to include gains and losses, Oracle Projects uses the Realized Losses Account transaction to derive the default accounting for the losses account. The process PRC: Revaluate Funding for a Single Project or PRC: Revaluate Funding for a Range of Projects calculates gains and losses. If the process calculates a loss, then it creates a Realized Loss billing event to reduce the project revenue.

When you run the process PRC: Generate Draft Revenue, it uses the Event Revenue function to derive a default debit account.

When you run the process PRC: Generate Revenue Accounting Events, it uses the Realized Losses Account transaction to derive a default credit account.

Fremont Corporation Realized Losses Account

Fremont corporation uses one expense account to record realized losses:

Define a Rule to Determine Account Segment Value:

To implement the Realized Losses transaction, Fremont defines a rule to supply the Realized Losses account code for the Account segment of its Accounting Flexfield.

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the Realized Losses Account and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Project Company
1 Cost Center Project Cost Center
2 Account Realized Losses

Related Topics

Generate Revenue Accounting Events, Oracle Projects Fundamentals

Accounting for Inter-Project Transactions

When you define an internal supplier site, you specify a Payables account created for internal billing purposes and a payables liability account for internal invoices. See: Setting Up for Inter-Project Billing.

Accounting for Invoice Rounding

When you generate an invoice, Oracle Projects converts functional currency amounts to invoice currency, if the functional currency is different from the invoice currency. After you interface Oracle Projects invoices to Oracle Receivables, Oracle Receivables converts invoice currency amounts to functional currency, if the invoice currency is different from the functional currency. The process of rounding to the nearest currency unit may produce a different amount from the original currency amount in Oracle Projects. Oracle Projects creates an extra distribution line to reconcile any difference (the rounding amount) and uses the Rounding Account transaction to determine the default rounding account.

Oracle Projects interfaces the default accounting that it creates using AutoAccounting to Oracle Receivables along with the associated customer invoice. In turn, Oracle Receivables creates accounting in Oracle Subledger Accounting. You can set up your own Oracle Receivables rules in Oracle Subledger Accounting to overwrite the default rounding account.

For a detailed explanation of Invoice Rounding, see: Invoice Rounding.

Note: You must set up an Invoice Rounding Account, even if you do not plan to process invoices in currencies other than the functional currency. If you do not, the process PRC: Generate Draft Invoices process issues an error and will not run.

Fremont Corporation Invoice Rounding Account

Fremont Corporation uses one liability account to store rounding amounts:

Define a Rule to Determine Account Segment Value:

To implement the Rounding Account transaction, Fremont defines a rule to supply the Rounding Account code for the Account segment of its Accounting Flexfield.

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the Invoice Rounding Transaction and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Project Company
1 Cost Center Project Cost Center
2 Account Invoice Rounding

Invoice Rounding

When currencies are converted, it is necessary to round figures to the nearest currency unit. When an amount is converted from currency A to currency B (and rounded to the nearest unit), then converted back to currency A, a rounding difference can occur. This can occur during the following sequence of events:

  1. You generate a project invoice in functional currency

  2. Oracle Projects then converts the invoice to the invoice currency (if it is different from the functional currency).

  3. Oracle Receivables converts the invoice to the functional currency for transfer to Oracle Subledger Accounting.

The rounding that takes place during each conversion can produce different amounts for the same invoice in the same currency code.

Oracle Projects creates rounding entries to ensure that amounts in the same currency are in agreement after the conversions take place. The rounding entries are posted to the Invoice Rounding Account.

Rounding Invoice Lines

When Oracle Projects generates an invoice, the invoice generation process converts each invoice line amount from the functional currency to the invoice currency if the two currencies are different. This conversion also occurs when you use the Recalculate option in the Invoice Review windows.

When you run the PRC: Interface Invoices to Receivables process, Oracle Projects debits a default asset account (usually an Accounts Receivable account), and credits the default Unbilled Receivables or Unearned Revenue account, based on the revenue and invoice balances of the project.

Rounding in the Interface Process

During the Interface Invoices to Receivables process, Oracle Projects determines if a rounding difference will occur later, during the conversion (in Oracle Receivables) from the invoice currency to the functional currency. If there is a rounding difference, Oracle Projects performs the following additional steps:

The Interface Invoices to Receivables process in Oracle Projects passes all the accounting entries to Oracle Receivables in both the transaction and functional currencies. The process determines if rounding has occurred and creates any additional rounding entries that are needed. The rounding entries are stored in Oracle Projects with the accounting amounts in the functional currency.

The additional rounding and the offsetting entry are created at the invoice line level, so that each invoice line is in balance. These rounding entries are passed to Receivables in the functional currency, to offset the Unbiled Receivables and Unearned Revenue accounts.

When Oracle Receivables creates accounting for the invoice in Oracle Subledger Accounting, it includes the rounding entry. You can set up your own Oracle Receivables rules in Oracle Subledger Accounting to overwrite the default rounding account that Oracle Projects derives using AutoAccounting.

Note: Because the Invoice Rounding account is required when interfacing invoices to Oracle Receivables (even if you are not using multiple currencies in invoicing), the Generate Draft Invoices process does not run unless the Invoice Rounding AutoAccounting function transaction is defined.

Verification in the Tieback Process

During the Tieback Invoices from Receivables process, Oracle Projects compares the functional currency amount in Oracle Projects to the functional currency amount in Oracle Receivables for each invoice line.

If these amounts are different, this indicates that the applicable conversion rate was modified between the conversion in Oracle Projects and the conversion in Oracle Receivables. If this occurs, Oracle Projects reports a warning in the Successful Invoice Transfers report. This warning is displayed in the Invoice Exception region of the Invoice window.

If this warning occurs, you must cancel the affected invoice in Oracle Projects to credit it.

Example of Invoice Rounding

Following is an example of Invoice Rounding for a multi-currency invoice.

In this example, the project has an unbilled receivables amount of 0.33. An invoice is then generated for the project.

Converting to the Invoice Currency

In this example, the project uses an invoice currency that is different from the project functional currency. When this is the case, Oracle Projects may have to adjust the converted amounts so that the total invoice amount matches the totals of the converted invoice line amounts. The adjustment is made in the last line of the invoice.

The following table shows the conversion of invoice line amounts from the project functional currency to the invoice currency. In this example, line 3 is adjusted by 0.01 so that the converted amount of the total invoice equals the total of the converted line amounts.

Line Number Project Functional Currency Amount Invoice Currency Amount: Conversion Rate = 0.1
Line 1 0.22 0.02
Line 2 0.22 0.02
Line 3 0.22 0.02 + 0.01
(adjusted to reconcile the converted invoice total)
Total 0.66 0.07 (0.66 x 0.1)

Converting to the Functional Currency

The following table shows the conversion of invoice line amounts from the project functional currency to the invoice currency (in Oracle Projects) and from the invoice currency to the functional currency (in Oracle Receivables). Before the rounding entries are created, the invoice currency amounts (column 1) do not agree with the functional currency amounts (column 4).

Column 5 shows the rounding entries that Oracle Projects creates so that the functional currency amount sent to Oracle Subledger Accounting agrees with the original project functional currency amount for each invoice line.

Invoice Line Number (1) Oracle Projects:
Project Functional Currency
(2) Oracle Projects:
Invoice Currency: conversion rate = .01
(3) Oracle Receivables:
Invoice Currency
(4)Oracle Receivables:
Functional Currency
(5) Oracle Subledger Accounting:
Rounding Entries (Functional Currency)
(6) Oracle Subledger Accounting:
Balance (Functional Currency)
1 0.22 0.02 0.02 0.20 0.02 0.22
2 0.22 0.02 0.02 0.20 0.02 0.22
3 0.22 0.02 + 0.01 0.03 0.30 (0.08) 0.22
Total 0.66 0.07 0.07 0.70 (0.04) 0.66

Amounts Sent to Oracle Subledger Accounting and Posted to Oracle General Ledger

When Oracle Projects creates rounding entries, Oracle Receivables sends the resulting amounts to Oracle Subledger Accounting. Oracle Subledger Accounting transfers the amounts to Oracle General Ledger for posting. The following table shows the amounts posted in Oracle General Ledger.

Invoice Accounting Line (1) Oracle Projects:
Project Functional Currency
(2) Oracle Projects:
Invoice Currency: Conversion Rate = .01
(3) Oracle Receivables:
Invoice Currency
(4) Oracle Receivables:
Functional Currency
Line 1 UBR 0.22 0.02 0.02 0.20
Line 1 UBR     0.00 0.02
Line 1 Rounding     0.02 0.02
Line 2 UBR 0.11 0.01 0.01 0.10
Line 2 UER 0.11 0.01 0.01 0.10
Line 2 UBR     0.00 0.01
Line 2 UER     0.00 0.01
Line 2 Rounding     0.00 0.02
Line 3 UER 0.22 0.02 + 0.01 0.03 0.30
Line 3 Rounding     0.00 (0.08)
Total AR 0.66 0.07 0.07 0.70

The total amounts posted to each account are shown in the following table:

Debit/Credit Account Invoice Currency Functional Currency
Credit UBR 0.03 0.33
Credit UER 0.04 0.33
Debit Receivables 0.07 0.70
Credit Rounding 0.00 0.04

After these amounts are posted, Oracle Subledger Accounting, Oracle General Ledger, and Oracle Projects have an Unearned Revenue balance of 0.33 and an Unbilled Receivables balance of 0.00 for this project.

Rounding for an Invoice Write Off

Oracle Projects calculates write-offs amounts in functional currency at the invoice line level, and converts each line to the invoice currency. If the original invoice is in a foreign currency, a rounding difference can occur.

If the write-off amount is not equal to the total amount of the original invoice, Oracle Projects prorates the write-off across all lines of the invoice. The write-off invoice is interfaced to Oracle Receivables where the AutoInvoice program converts the write-off invoice to the functional currency. Rounding differences can cause the Oracle Receivables amount to differ from the amount stored in Oracle Projects. Oracle Receivables creates accounting for the write-off amounts in Oracle Subledger Accounting. Oracle Subledger Accounting transfers the final write-off accounting to Oracle General Ledger for posting.

When you write off an invoice, Oracle Projects reverses the write off amount from the unbilled receivables account and adds it to a write-off expense account when you interface the write off to Oracle Receivables.

If there is a rounding difference in an invoice write off, Oracle Projects creates rounding entries at the invoice line level. Oracle Projects interfaces the rounding entries to Oracle Receivables in both the transaction and functional currencies. These entries ensure that write-off amounts in Oracle Projects, Oracle Receivables, Oracle Subledger Accounting, and Oracle General Ledger are all in balance.

Example of Rounding in an Invoice Write-Off

In this example, a write-off is entered for an invoice with three lines, each in the amount of 0.44 (invoice currency). The invoice total is 1.32. The write off is for 50% of the invoice.

The following table shows the conversion of invoice line amounts for the write-off. Before the rounding entries are created, the invoice currency amounts (column 1) do not agree with the functional currency amounts (column 4).

Column 5 shows the rounding entries that Oracle Projects creates so that the write-off amount in Oracle Projects (in the project functional currency) agrees with the write-off amount that Oracle Receivables calculates in the functional currency.

Invoice Line Number (1) Oracle Projects:
Invoice Currency
(2) Oracle Projects:
Invoice Currency: Conversion Rate = .01
(3) Oracle Receivables:
Invoice Currency
(4)Oracle Receivables:
Functional Currency
(5) Correction (Functional Currency)
Line 1 -0.22 -0.02 -0.02 -0.20 -0.02
Line 2 -0.22 -0.02 -0.02 -0.20 -0.02
Line 3 -0.22 -(0.02 + 0.01) -0.03 -0.30 0.08
Total -0.66 -0.07 -0.07 -0.70 -0.04

When Oracle Projects creates rounding entries, Oracle Receivables sends the resulting amounts to Oracle Subledger Accounting. Oracle Subledger Accounting transfers the amounts to Oracle General Ledger for posting. The following table shows the amounts posted in Oracle General Ledger.

Debit/Credit Line Number Account Invoice Currency Functional Currency
Debit   Receivables -0.07 -0.70
Credit 1 Write Off -0.02 -0.20
Credit 1 Write Off 0 -0.02
Credit 1 Rounding 0 0.02
Credit 2 Write Off -0.02 -0.20
Credit 2 Write Off 0 -0.02
Credit 2 Rounding 0 0.02
Credit 3 Write Off -0.03 -0.30
Credit 3 Write Off 0 0.08
Credit 3 Rounding 0 -0.08

The total amounts posted to each account are shown in the following table:

Debit/Credit Account Invoice Currency Functional Currency
Debit Receivables -0.07 -0.70
Credit Write Off -0.07 -0.66
Credit Rounding 0 -0.04

Related Topics

Setting Up Multi-Currency Billing

Overview of AutoAccounting

Accounting for Revenue and Billing

Accounting for Invoice Write-Offs

When you write off an uncollectible invoice, Oracle Projects uses the Invoice Write-Off Account transaction.

When you run the PRC: Interface Invoices to Receivables process, Oracle Projects may debit a default expense account (usually a write-off account) and credit a default asset account (usually an accounts receivable account).

Fremont Corporation Invoice Write-Off Account Transaction

Fremont Corporation uses one expense account to record invoice write-offs:

To implement the Write-Off transaction, Fremont uses an existing rule to supply the Write-Offs account code for the Account segment of its Accounting Flexfield.

Fremont also uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the Write-Off Transaction and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Project Company
1 Cost Center Project Cost Center
2 Account Write-Off

Setting Up for Inter-Project Billing

The following instructions give details about the Inter-Project Billing steps in the Oracle Project Billing Feature Implementation Checklist.

These setup steps are divided into the following phases:

Global Setup

Perform the following global steps to process inter-project billing in your system.

Define Additional Expenditure Types, Agreement Types, Billing Cycles, Invoice Formats, and Supplier Types for Intercompany Billing

These steps are optional. See: Defining Additional Expenditure Types, Agreement Types, Billing Cycles, Invoice Formats, and Supplier Types.

Operating Unit Setup

You need to perform these steps in each operating unit in which you want to process inter-project billing.

Define Supplier Sites for Internal Suppliers (Providers)

In Oracle Payables, define a supplier site for each internal supplier that provides inter-project billing transactions to the current operating unit. Payables invoices created by the inter-project billing process are sent to these supplier sites.

When you define an internal supplier site, specify a Payables account created for internal billing purposes. (A supplier site is required for each operating unit that will receive inter-project invoices from a provider project.) Specify a payables liability account for internal invoices. See: Suppliers, Oracle Payables User's Guide.

Define Customer Bill To and Ship To Sites for Internal Customers (Receivers)

In Oracle Receivables, define a customer bill and ship site for each internal customer that generates inter-project invoices from the current provider operating unit. This step is required for each provider operating unit. See: Oracle Receivables Implementation Guide.

Define Internal Billing Implementation Options

Define internal billing implementation options for every operating unit that uses the internal billing feature of Oracle Projects as either a provider or receiver organization. You can designate an operating unit as a provider organization, a receiver organization, or both.

See: Defining Internal Billing Implementation Options.

Define Provider and Receiver Controls

Specify in each receiver operating unit the provider's operating unit. No information needs to be specified in the provider operating unit. You can define the following types of provider and receiver controls:

See: Define Provider and Receiver Controls and Defining Intercompany Receiver Controls.

Setting Up Tax for Internal Oracle Receivables Invoices

In Oracle E-Business Tax, set up taxes and configure for each provider operating unit, see: Applying Tax to Project Invoices. For more information on tax setup and configuration, see the Oracle E-Business Tax User Guide.

See: Defining Tax Account Codes for Internal Receivables Invoices.

Setting Up Tax for Internal Oracle Payables Invoices

In Oracle E-Business Tax, set up taxes and configure for each receiver operating unit, see: Applying Tax to Project Invoices. For more information on tax setup and configuration, see the Oracle E-Business Tax User Guide.

Define Provider and Receiver Projects

Define receiver projects and provider projects for inter-project billing.

Define Receiver Projects

Define a receiver project for inter-project billing so that work on some or all of the chargeable, lowest tasks is performed on separate projects.

To define a receiver project, navigate to the Task Details window for the appropriate task. Select Receive Inter-Project Invoices to indicate that this task will receive inter-project invoices from one or more provider projects. You can select this option only if you have identified the current operating unit as a receiver operating unit and if the project does not use an intercompany billing project type.

See: Workplan Structures, Oracle Projects Fundamentals.

Define Provider Projects

Define a provider project to perform work on the lowest task of a receiver project. The project must be a contract project but cannot use an intercompany billing project type. You can define a provider project in any operating unit that has been identified as a provider operating unit.

To define a provider project for inter-project billing, enable the Bill another Project option on the Project Customers window. You then choose the receiver project and task to be billed.

See: Project Customers Window, Oracle Projects Fundamentals.

Define the Supplier Invoice Charge Account Process for Internal Invoicing

In Oracle Payables, modify the Account Generator process Supplier Invoice Charge Account so that it returns a generic cost account for internal invoices.

To differentiate between regular and internal invoices, you can modify the process to use different supplier types or to use specified naming conventions. You can further differentiate internal invoices between intercompany and inter-project invoices by specifying the appropriate Payables import source for Projects intercompany invoices and inter-project invoices.

See: Project Supplier Invoice Account Generation.

Implement the Payables Open Interface Workflow

See: Customizing the Payables Open Interface Workflow.

Implement the Inter-Project Billing Extensions

You can implement your business rules for inter-project billing by using the following client extensions:

See: Client Extensions, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

Customer Billing Retention

The following instructions give details about the Customer Billing Retention steps in the Oracle Project Billing Feature Implementation Checklist.

Overview of Defining Customer Billing Retention

Retention is a provision in a contract to hold back a portion of invoiced amounts for the duration of the project. Oracle Projects enables you to set up withholding and billing terms for retention, invoice retention amounts, and account for unbilled retention.

Defining the Retention Level

Retention provisions in contracts can vary greatly. Contracts may require that the withholding and billing of retained amounts for a project customer be managed at either the project or top task level. Contracts for work-based billing may require that amounts be withheld by expenditure category, while those for event-based billing require that amounts be withheld by event category. Contracts may also include a variety of conditions for the billing of withheld amounts.

For each project customer, you can define retention terms at either the project level or the top task level to reflect the granularity of the terms specified by the contract with the project customer. You cannot change the retention level after an amount has been withheld for the project customer.

Defining Retention Terms

Retention Terms determine how amounts are withheld from project invoices and how the withheld amounts are billed to the project customer. Retention terms include:

These terms apply to all sources of project invoice amounts for the specified project or top task. For each term, you can define a withholding percentage or amount. Optionally, you can define a threshold amount that represents the maximum amount to be withheld per term.

Each term represents a retention withholding basis. This basis is used to determine the grouping of retention lines on project invoices. You can optionally define more detailed withholding terms by expenditure category for work-based billing, or by event revenue category for event-based billing.

Billing Terms

Retention invoices bill project customers for previously withheld retention amounts. Billing terms control the timing and calculation of retention invoices. You define retention billing terms at the same retention level as retention withholding terms.

When you define a billing term, you can select one of the following retention billing methods:

Define Billing Implementation Options for Customer Billing Retention

To account for unbilled retention separately from other billing, you enable the Account for Unbilled Retention functionality in the Billing region of the Implementation Options window.

Only projects that are created after the Account for Unbilled Retention has been enabled can account for unbilled retention separately from unbilled receivables.

You cannot disable the value of this option after a project or project template has been created in an operating unit.

See: Billing Implementation Options.

Define Invoice Formats for Customer Billing Retention

An invoice format determines how Oracle Projects creates an invoice line. You can define different formats for retention and retention billing invoice line items.

Retention Format

When you define a retention invoice format, you can define the following columns:

Column Description
Withholding Percentage or Amount Withholding percentage or withholding amount
Text User-defined text
Withholding Term The details of the withholding term. These details include:
For expenditure items: project or top task, expenditure category, expenditure type, non-labor resource, and effective dates
For events: project or top task, revenue category, event type, and effective dates
Withholding Basis Amount Amount of the withholding basis
Invoice Processing Currency the invoice processing currency of the withholding basis amount and withholding amount

Retention Billing Format

The Retention Billing invoice format is used to bill project customers for previously withheld retention amounts. When you define a retention billing invoice format, you can define the following columns:

Column Description
Retention Billing Method The retention billing method assigned to the project or top task
Retention Method Value The value displayed varies depending on the billing method used, as listed below:
Percent complete: The percentage complete defined for the billing term
Total withheld amount: The total amount defined for the billing term
Billing cycle: The name of the cycle defined for the billing term
Client extension: No value is displayed
Total withheld amount The total amount withheld for the project or top task
Billing percentage or amount The billing percentage or amount used to derive the retention billing amount
Text User-defined text
Invoice processing currency Invoice processing currency of the total withheld amount and billing amount

For information on defining invoice formats, see: Invoice Formats.

Accounting for Unbilled Retention

When you withhold a retention amount on an invoice and want to track the unbilled retention amount separately, Oracle Projects uses the Unbilled Retention Account transaction.

When you run the PRC: Interface Invoices to Receivables process, Oracle Projects may credit an asset account (usually an unbilled retention account). This transaction derives a separate account for the unbilled retention amounts on project and retention invoices.

Fremont Corporation Unbilled Retention Account Transaction

Fremont corporation uses one asset account to record unbilled retention:

Define a Rule to Determine Account Segment Value:

To implement the Unbilled Retention transaction, Fremont defines a rule to supply the Unbilled Retention account code for the Account segment of its Accounting Flexfield.

Fremont uses existing rules to supply values for the Company and Cost Center segments of its Accounting Flexfield.

Enable the Unbilled Retention Transaction and Assign Rules:

Fremont enables the following transaction:

The segment rule pairings for this transaction are shown in the following table:

Segment Number Segment Name Rule Name
0 Company Project Company
1 Cost Center Project Cost Center
2 Account Unbilled Retention

Integration with Oracle Receivables

The following instructions give details about the Integration with Oracle Receivables steps in the Oracle Project Billing Feature Implementation Checklist.

Implementing Oracle Receivables for Oracle Projects Integration

Oracle Projects interfaces with Oracle Receivables to process your invoices and track customer payments.

Oracle Projects predefines all of the information required for the Oracle Receivables AutoInvoice program to process Oracle Projects invoices.

If you have installed Oracle Receivables, read this section in conjunction with the set up steps for Oracle Receivables in the Oracle Receivables Implementation Guide.

Defining Transaction Types for Invoice Processing

Oracle Projects generates draft invoices and uses Oracle Receivables features to generate accounting in Oracle Subledger Accounting, transfer the final accounting to Oracle General Ledger, and maintain and track customer payments on them. Oracle Receivables uses transaction types to determine whether the transaction generates an open receivable balance and whether it posts to Oracle General Ledger.

Oracle Projects predefines two transaction types to process your invoices in Oracle Receivables:

Transaction types used by Oracle Projects must have a creation sign value of Any Sign and the Open Receivable check box must be checked.

Note: If the Allow Overapplication option box is not enabled and the balance of the invoice being credited is less than the amount of the credit memo, credit memos created in Oracle Projects may fail to import. If this occurs, review and adjust the invoice receipt applications as appropriate. Then run the AutoInvoice process again to import the rejected credit memos.

Before you make changes to the transaction types for invoicing, verify that the predefined PROJECTS INVOICES Batch Source is accurate. You should see the following values:

Oracle Projects assigns a transaction type to an invoice transaction in one of the ways described below.

If you enable tax calculation through Oracle Receivables, you should enable tax calculation on the transaction types defined for Oracle Projects.

Implementing Decentralized Invoicing

With decentralized invoicing, you allow organizations to process their own invoice collections. Oracle Projects and Oracle Receivables provide you with a way to easily report and query invoices in Oracle Receivables by organization.

When you interface draft invoices to the Oracle Receivables interface tables, Oracle Projects locates the project managing organization and moves up the organization hierarchy "tree" to the lowest-level Project Invoice Collection organization at or above the project managing organization to assign the appropriate transaction type to each invoice.

After validation, the AutoInvoice Import Program moves the draft invoices and their assigned transaction types into the Oracle Receivables invoice tables. When you use this method, you can run reports and process Oracle Receivables invoices by organization by selecting the Project Invoice Collection organization name for the transaction type parameter.

To implement decentralized invoicing:

  1. Determine which organizations process invoices.

  2. Define those organizations with the Project Invoice Collection Organization classification enabled. See: Organizations.

  3. Define or update the Project/Task Owning Organization Hierarchy to include the relevant Project Invoice Collection organizations. See: Organization Hierarchy.

  4. Disable the Centralized Invoice Processing check box when you define implementation options for Oracle Projects. See: Billing Implementation Options.

  5. Run the IMP: Create Invoice Organization Transaction Types process.

    This process defines transaction types for you in Oracle Receivables:

  6. The transaction types have the same name as the project invoice collection organization in the base language. See: Multilingual Support in Oracle Projects, Oracle Projects Fundamentals.

  7. You can rerun the process any time you add new organizations or change organization names.

    Note: If you specify an organization type in the Invoice Processing Organization Level of the Billing Implementation Options, you must run the IMP: Create Invoice Organization Transaction Types process before you can successfully interface invoices from Oracle Projects.

Implementing Centralized Invoicing

With centralized invoicing, one group or organization processes all invoices. All Oracle Projects invoices are created in Oracle Receivables with the same invoice type of Projects Invoice or Projects Credit Memo for the processing operating unit.

If you select Centralized Invoicing (the system default) in Oracle Projects Implementation Options, Oracle Projects assigns the default transaction types assigned to the invoice batch source specified in the Oracle Projects implementation options.

The predefined transaction types are the default transaction types of the Projects invoice batch source. After validation, AutoInvoice assigns the default values from the invoice batch source to invoices and copies those transaction types into the invoice tables.

AR Transaction Type Extension

You can also use the AR Transaction Type Extension to determine the AR transaction type when you interface invoices to Oracle Receivables. See: AR Transaction Type Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference. You can use this extension whether you use centralized or decentralized invoicing.

Related Topics

Implementation Options

Create Invoice Organization Transaction Types, Oracle Projects Fundamentals

Importing Transaction Information Using AutoInvoice, Oracle Receivables User's Guide

Defining Automatic Accounting in Oracle Receivables

Because the Automatic Accounting feature in Oracle Receivables is different from the AutoAccounting feature in Oracle Projects, you need to define Automatic Accounting for both Oracle Receivables and Oracle Projects.

The Oracle Receivables Automatic Accounting feature determines default general ledger accounts for your invoice transactions. You need to implement Oracle Receivables AutoAccounting before you can run the Oracle Receivables AutoInvoice feature.

However, Oracle Projects invoices do not use the AutoAccounting transactions created by Oracle Receivables. The accounting transactions determined by the AutoAccounting feature in Oracle Projects are passed to the AutoInvoice interface tables and are used by AutoInvoice when creating invoices in Oracle Receivables. The only AutoAccounting codes in Oracle Receivables that are used for Oracle Projects invoices are those for tax. If you use AutoInvoice to import invoices from another source, you need to define AutoAccounting codes that apply to those invoices.

You use the Oracle Receivables Accounting window to set up automatic account codes for the following account types. You need to define account codes for each account type.

You provide specific information to indicate how you want Oracle Receivables to generate the account codes.

Defining Subledger Accounting for Oracle Receivables

Oracle Subledger Accounting is an intermediate step in the accounting flow between subledger applications and Oracle General Ledger.

Oracle Receivables creates accounting in Oracle Subledger Accounting, including the accounting for customer invoices from Oracle Projects. Oracle Subledger Accounting transfers the final accounting to Oracle General Ledger.

If you define your own detailed accounting rules in Oracle Subledger Accounting, then Oracle Subledger Accounting overwrites default accounts, or individual segments of accounts, that Oracle Receivables derives using the Account Generator. To define your own Oracle Subledger Accounting setup for Oracle Receivables, you must access the Accounting Methods Builder from an Oracle Receivables responsibility. For more information, see the Oracle Subledger Accounting Implementation Guide.

Related Topics

Accounting for Receivables, Oracle Receivables Implementation Guide

Salespersons and Credit Types

You can interface sales credit information for project invoices to Oracle Receivables for sales commission reporting. If you choose to not interface sales credit information to Oracle Receivables, you can use credit receiver information in Oracle Projects for reporting purposes. This essay describes how to implement Oracle Receivables and Oracle Projects for the method your company chooses.

Transferring Sales Credit to Oracle Receivables

If you want to interface sales credit information to Oracle Receivables, during your implementation of Oracle Receivables for Oracle Projects, you enable the Require Salespersons option in the System Options window. This section continues your implementation of sales credit receivers.

You can interface sales credit information to Oracle Receivables for project invoices. Sales credit information is based on credit receivers you enter in Oracle Projects. If you interface sales credits to Oracle Receivables, the credit receiver must set up as a salesperson in Oracle Receivables and the credit type must be a sales credit type in Oracle Receivables.

You enter credit receivers at the project level using the Credit Receivers window located under the Billing Information option. You interface the information to Oracle Receivables by enabling the Transfer to AR option.

Set the Require Salesperson Option

If you want to interface sales credit information to Oracle Receivables, enable the Require Salesperson option in the System Options window in Oracle Receivables.

Define Sales Credit Types

You use the Oracle Order Management Sales Credit Types window to define the type of credit you want to allocate to salespersons in Oracle Receivables for project invoices. You can use sales credit types to determine if sales credit is a quota or non-quota amount. See: Defining Sales Credit Types, Oracle Order Management User's Guide.

Note: If you do not have Oracle Order Management installed, use the predefined sales credit type of Quota Sales Credit when you define salespersons. Using this sales credit type allows you to use sales credits without having Oracle Order Management installed.

Define Salespersons

When you interface Oracle Projects invoices to Oracle Receivables, Oracle Projects assigns a primary salesperson to the invoice and interfaces sales credit lines for the invoice based on the project's credit receivers.

Oracle Projects assigns the project manager on the project as the primary salesperson as long as the project manager is defined as a salesperson in Oracle Receivables. Using the primary salesperson as the criteria, you can use Oracle Receivables reports and windows to review invoices by project manager. If you want to use this type of functionality, you must define all project managers as salespersons in Oracle Receivables.

Oracle Projects also credits the sales credit lines for the invoice using the project's credit receivers specified for interface to Oracle Receivables. You must define all employees that may be credit receivers for which you want to interface sales credit as salespersons in Oracle Receivables.

Before you can set up an employee as a salesperson, you must import the employee from Oracle Human Resources into the Resource Manager to create a resource. To set up a new or existing resource as a salesperson, see Oracle Common Application Components Implementation Guide.

Next, you set up your salespersons and assign sales territories using the Resource window. For Oracle Projects, assign the salesperson the Sales role type, Sales Representative role, and Quota Sales Credit sales credit type. In addition, enable the Active for Receivables check box for the operating unit on the Receivables tab. For additional information about defining salespersons, see Oracle Receivables Implementation Guide.

Note: Information that you enter in the Resources window is shared by Oracle Receivables, Oracle Customer Relations Management (CRM), Oracle Sales, and Oracle Sales Compensation.

Important: The name you enter in the Resources window when you define a salesperson must be identical to the name you enter in the Oracle Human Resources Enter Person window. Use the following format when you define salespersons: Last name, Prefix, First name (Middle name).

Set the Allow Sales Credits Option

If you want to send salesperson information to Oracle Receivables, you need to enable the Allow Sales Credits option in the Transaction Sources window for the predefined batch source of PROJECTS INVOICES. When you set this option to Yes, Oracle Receivables ensures that sales credit lines are assigned valid credit types as defined in Oracle Order Management and have valid salesperson as defined in Oracle Receivables.

The Allow Sales Credit option is located in the AutoInvoice Options tab of the Transaction Sources window. If you navigate to the Transaction Source window and query by Name = PROJECTS INVOICES, you will then be able to go to the AutoInvoice Options tab. The AutoInvoice Options tab is only available for transaction sources with type = Imported. See also: Transaction Batch Sources, Oracle Receivables Implementation Guide.

To Transfer Sales Credit Information to Oracle Receivables:

  1. Set the Require Salesperson System Option in Oracle Receivables to Yes.

  2. Define sales credit types using the Oracle Order Management Sales Credit Types form, or use the predefined sales credit type of Quota Sales Credit, if Oracle Order Management is not installed.

  3. Define as salesperson all project managers and other employees who may be credit receivers.

  4. Enable the Allow Sales Credits option in the AutoInvoice Options tab of the Transaction Sources window in Oracle Receivables.

  5. Enter credit receivers for your contract projects using the Credit Receivers windows in the Billing Information option at the project level.

Reporting Credit Information in Oracle Projects

You can assign credit receivers in Oracle Projects for invoices at the project level, using credit types that you define in Oracle Projects. You do not have to interface salesperson credit information to Oracle Receivables; you can use Oracle Projects tables to create custom reports on the information.

You use credit receivers in Oracle Projects to award different kinds of revenue credit to your employees, such as marketing credit or quota credit. For example, if you want to credit an employee for bringing in a contract in a market sector for which you currently have few or no projects, you can define a credit type with a name such as Diversity Credit. After you define the project, you specify the employee as a credit receiver of Diversity Credit.

Disable the Require Salesperson Option

If you do not want to interface sales credit information to Oracle Receivables, during your implementation of Oracle Receivables for Oracle Projects disable the Require Salesperson option of the System Options window.

Define Credit Types

You use the Oracle Projects Credit Types window to specify the kind of revenue credit you want to assign employees in Oracle Projects. Oracle Projects predefines the credit type of Quota Credit. See: Credit Types.

Fremont Corporation Credit Types

Fremont Corporation awards Marketing Credit to a marketing staff member who generates a lead. Fremont also awards Quota Credit to a staff member who brings in a project.

The following table shows Fremont's credit types:

Credit Type Name Description
Marketing Credit Credit for generating leads
Quota Credit Credit for acquiring a project

Set the Allow Sales Credits Option

If you do not want to send sales credit information to Oracle Receivables, leave this option set to No.

Fremont Corporation: Sales Credits Option

Fremont Corporation's implementation team does not enable the Allow Sales Credits option:

Define Salespersons

Oracle Projects assigns the primary salesperson as the manager on the project, if you have defined the project manager as a salesperson in Oracle Receivables. Using the primary salesperson as the criteria, you can use Oracle Receivables reports and forms to review invoices by project manager. If you want to use this type of functionality, you must define all project managers as salesperson in Oracle Receivables. See: Salespersons and Credit Types.

To Report Sales Credit Information in Oracle Projects Only:

  1. Set the Require Salesperson System Option in Oracle Receivables to No.

  2. Define sales credit types using the Oracle Projects Credit Types form.

  3. Define all project managers as salesperson in Oracle Receivables. This way you can still retrieve AR information by primary salesperson in Oracle Receivables.

  4. Leave the Allow Sales Credits option in the AutoInvoice Options tab of the Transaction Sources window in Oracle Receivables disabled.

  5. Create custom reports on the credit receiver information in the Oracle Projects table.

Implementing the Receivables Installation Override Extension

The Receivables Installation Override client extension enables you to use a third-party receivables system for the majority of your Receivables functionality, yet have the ability to import customer data from Oracle Receivables.

Without this client extension, you can only import customer data with a full installation of Oracle Receivables.

To use this capability, you must complete a full installation of Oracle Receivables, then override the installation mode to shared using the Receivables Installation Override extension.

For more information, see: Receivables Installation Override Extension, Oracle Projects APIs, Open Interfaces, and Client Extensions Reference.