Implementing Oracle Project Billing

This chapter contains instructions for implementing Oracle Project Billing.

This chapter covers the following topics:

• Oracle Project Billing Implementation Checklists
• Licensing Oracle Project Billing
• Revenue and Invoicing
• Setting Up for Agreements and Funding
• Customers
• Accounting for Revenue and Billing
• Setting Up for Inter-Project Billing
• Customer Billing Retention
• Integration with Oracle Receivables

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:

• Purge Interface Tables: Enabled

• Require Salesperson: Disabled

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:

• A customer may be tax exempt for all services provided.

• A tax authority may require taxing all labor and materials.

• A tax authority may require that only labor is taxed.

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.

• A customer, the customer’s bill-to or ship-to site, and to the system options for Oracle Receivables on the Application Tax Options page in Oracle E-Business Tax

• A project, an expenditure type, an event, and for retention billing In Oracle Projects

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.

• eBTax: Allow Override of Tax Classification Code

• eBTax: Allow Override of Customer Exemptions

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.

• Customer Site.

  Assign a tax classification code to a customer location when setting up Party Tax Profiles in Oracle E-Business Tax. If you use this source, then the following logic determines the tax classification code that Oracle E-Business Tax selects at the customer site level.

  • If you select a tax classification code for the customer ship-to site, then Oracle E-Business Tax uses this code as the default.

  • If you do not select a tax classification code at the customer ship-to site, then Oracle E-Business Tax uses the tax classification code that you assign to the customer bill-to site.

• Customer.

  Assign a tax classification code to a customer when setting up Party Tax Profiles in Oracle E-Business Tax.

• Oracle Receivables System Option.

  Assign a tax classification code to this financial tax option when defining tax options for Oracle Projects and the project operating unit.

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.

• Project.

  In the Billing Setup project option window, you can enter a default tax classification code for billing. See: Project Options: Billing Setup, Oracle Projects Fundamentals.

• Expenditure Type Level.

  In the Expenditure Types window, you can enter a default tax classification code for each expenditure type. See: Defining Expenditure Types.

• Event Type Level.

  In the Event Types window, you can enter a default tax classification code for each event type. See: Defining Event Types.

• Retention Level.

  In the Billing Setup project option window, you can enter a default tax classification code for retention billing. See: Project Options: Billing Setup, Oracle Projects Fundamentals.

• Output Tax Client Extension.

  Oracle Projects provides the Output Tax client extension to enable you to address the unique requirements of your business. You can use this extension to implement and automate company-specific rules for assigning default tax classification codes to invoice lines. For more information, use the Integration SOA Gateway responsibility to access the Oracle Integration Repository and navigate to the Projects Suite to find the Output Tax Client Extension.

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:

• If the Default Tax Classification check box is enabled, Oracle Receivables imports the default tax classification codes on invoice lines from Oracle Projects.

  When you enable this check box, you must ensure that each invoice line has a tax classification code. If the tax classification code on the customer invoice is missing, then the Interface Invoices to Receivables process rejects the invoice. You must then return to the Invoice Review window, assign the tax classification code to the invoice, and rerun the interface process.

• If the Default Tax Classification check box is disabled, the Interface Invoices to Receivables process does not check to see if the invoice contains the tax classification code.

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:

• Two employee-based bill rate schedules:

  • Standard: A standard corporate schedule

  • Hazardous Work: A hazardous work schedule used in Fremont Engineering's Environmental group

• Block Rates: A job-based schedule for the Construction group, which bids using block rates for highly competitive jobs

• Standard Non-Labor: An expenditure type-based schedule to bill clients for non-labor items. In this schedule, each expenditure type is assigned either a bill rate or a markup percentage.

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:

• The groups in your organization that create and print invoices

• The printers and types of printers available for printing invoices

• The preformatted paper that your company uses to print invoices

• The frequency of creating and printing invoices in your organization

• The timing of invoice printing in the invoicing flow

• The different types of invoice layouts required by groups in your company or for certain types of projects

• The exact layout of the invoice, including the header and detail regions, when printed on paper

• The detail backup reports required for invoicing

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:

• Selects eligible expenditure items for invoicing

• Groups selected expenditure items according to the grouping defined for a project's invoice format

• Selects expenditure item information and adds text objects to produce final invoice lines as determined by the invoice format detail on the project invoice format.

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

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:

• Labor Invoice Format

  • Expenditure items are grouped by Employee

  • The invoice lines show the following detail: Employee Last Name, ",", Employee First Name, Job, Total Hours, Hrs@$, Bill Rate

• Non-Labor Invoice Format

  • Expenditure items are grouped by Expenditure Type

  • The invoice lines show the following detail: Expenditure Type, Total Amount, Units

• Retention Invoice Format

  • Expenditure items are grouped by Retention

  • The invoice lines show the following detail: % Retention

Sample invoice lines: Project A

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:

• Labor Invoice Format

  • Expenditure items are grouped by Work Site, Job

  • The invoice lines show the following detail: Site, Work Site City, Services Level, Job, Hours, Total Hours

• Non-Labor Invoice Format

  • Expenditure items are grouped by Work Site, Category, Type

  • The invoice lines show the following detail: Site, Work Site City, Expenditure Type, Non-Labor Resource, Total Amount, Units

Sample invoice lines: Project B

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:

• Labor Invoice Format

  • Expenditure items are grouped by Top Task, Employee

  • The invoice lines show the following detail: Top Task Number, Top Task Name, Employee Full Name, Total Hours, Hours at the hourly rate of, $ Bill Rate

• Non-Labor Invoice Format

  • Expenditure items are grouped by Top Task, All

  • The invoice lines show the following detail: Top Task Number, Top Task Name, - -, Expenses

Sample invoice lines: Project C

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.

   • Code

   • Meaning

   • Description

   • Tag Value (optional -- tag value is not used by Oracle Projects)

   • Effective Dates

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:

• Automatic. An Automatic classification generates an automatic event for revenue or invoice amounts that may be positive or negative, depending on your implementation of billing extensions. See: Billing Extensions, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

• Deferred Revenue. A Deferred Revenue classification generates an invoice for the amount of the event, and has no immediate effect on revenue.

• Invoice Reduction. An Invoice Reduction classification reduces the amount of an invoice without affecting revenue. For example, you can use an invoice reduction event to give a discount to a customer on a particular invoice.

• Manual. A Manual classification allows you to enter both a revenue amount and a bill amount. These two amounts can be different. Classify an event type as manual when you need to indicate different revenue and bill amounts.

• Scheduled Payment. A Scheduled Payment classification generates an invoice for the amount of the event. Oracle Projects marks expenditure items on the project being invoiced on a first-in first-out (FIFO) basis up to the amount of the event. When you use this classification, you can show details of an invoice in the Invoice Review window by pressing the Details button. The details do not calculate the bill amount and are never printed on the invoice.

  Important: Events with Scheduled Payment classification can be entered for any project irrespective of whether the Invoice Method is Event. However, when schedule payment events are entered for projects with Invoice Method as Event, the expenditure items are marked with the event number on a first-in-first-out basis (FIFO) when processing the event. If the Invoice Method is other than Event, the schedule payment events are processed as manual events and the underlying expenditure items are not marked with the event number.

• Write-On. A Write-On classification causes revenue to accrue for the amount of the write-on. A Write-On also adds the write-on amount to the subsequent invoice. Revenue and invoice amounts are identical. For example, when your business earns a bonus for completing a project on time or under budget, you can define an event type with the Write-On classification to account for the bonus amount. A write-on causes revenue to accrue and generates an invoice to bill your client for the bonus amount.

• Write-Off. A Write-Off classification reduces revenue by the amount of the write-off.

• Realized Gains: A Realized Gain classification allows you to create an event to support reclassification of realized gains during funding revaluation.

• Realized Loss: A Realized Loss classification allows you to create an event to support reclassification of realized losses during funding revaluation. See Funding Revaluation, Oracle Projects Fundamentals.

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

• Define Event Types. See: Event Types.

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:

   • Percent Complete Revenue

   • Percent Complete Invoicing

2. Project Setup:

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

   • Use the Event/Work rule if you want to accrue revenue based on percent complete.

   • Use the Work/Event or Cost/Event rule if you want to generate invoices based on percent complete.

   • Use the Event/Event rule if you want to both accrue revenue and generate invoices based on percent complete.

   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:

• Budget Amounts. You specify which cost and revenue budget types to use in the calculation on the billing extension definition. If you do not specify values, the budget types Approved Cost Budget and Approved Revenue Budget are used. The last baselined budget version of the specified budget types are used. See: Billing Extensions, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.

• Cost Amounts for WIP. You determine whether to base your cost accrual on the budgeted raw cost or the budgeted burdened costs. You specify this on the definition of the billing extension. This also defines what cost amounts are accounted for as cost WIP. You must set up your AutoAccounting rules to account for the appropriate cost amounts as cost WIP.

• Event Types to use for Events. You specify which event types to use when creating the events which result in the Cost Accrual, Cost Accrual Contra, and reversing Cost WIP entries.

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

• In the calculation in the Revenue-Based Cost Accrual Formula Example, there is no relationship between the costs entered in the system and the cost accrual amounts generated by the Cost Accrual Billing Extension during the life of the project. The cost accrual amounts are calculated based on the actual accrued revenue, the budgeted cost amounts, and the budgeted revenue amounts.

• If the result of the formula in the Revenue-Based Cost Accrual Formula Example is zero or less than zero, no event is created. Cost accruals cannot be negative.

• If the budgeted costs are greater than the budgeted revenue amounts (the project is incurring a loss), then the accumulated cost accrual will be greater than the accumulated accrued revenue.

• Events are created at the funding level (project or top task).

• The billing extension example creates events that use only one account for each of the corresponding buckets: Cost Accrual, Cost Accrual Contra, and Cost WIP (for the reversing entries at project closing).

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:

• Cost Accrual

• Cost Accrual Contra

• Cost WIP (for reversing entries during project closing)

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:

• Cost Accrual Identifier. This value is used by the project verification rules and project status columns extensions to identify events created from the cost accrual billing extension. You must define the cost accrual identifier with a value of COST-ACCRUAL in the ATTRIBUTE11 column. You can define a value set with just one value that is uppercase. The minimum and maximum value is COST-ACCRUAL, with a maximum size of 12.

• Cost Accrual Event Type in the ATTRIBUTE12 column.

• Cost Accrual Contra Event Type in the ATTRIBUTE13 column.

• Cost WIP Event Type in the ATTRIBUTE14 column.

• Cost Basis in the ATTRIBUTE15 column. The cost basis specifies whether to use raw or burdened costs as the Cost WIP and raw or burdened budgeted costs in the cost accrual calculation. The two possible values are R and B. You can define a value set with just two values that are uppercase. The minimum value is B and the maximum value is R. The maximum size is 1.

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:

• Procedure: pa_rev_ca.calc_ca_amt. This is the example procedure provided by Oracle Projects. Use your own procedure name, as appropriate.

• Calling Place: Post Regular Processing

• Calling Process: Revenue

• Transaction Independent: Yes

Fremont Corporation Cost Accrual Implementation

Fremont Corporation implements cost accrual as shown below:

• Cost Accrual Billing Extension:

  • Name: Cost Accrual

  • Procedure: pa_rev_ca.calc_ca_amt

  • Description: Calculate cost accrual amount

  • Order: 10

  • Calling Process: Revenue

  • Default Event Type: Cost Accrual

  • Event Description: Cost Accrual Based on Revenue

  • Default Cost Budget: Approved Cost Budget

  • Default Revenue Budget: Approved Revenue Budget

  • Calling Place: Post-Regular Processing

  • Required Inputs: None

  • Other Parameters: Transaction Independent: enabled; Project Specific: not enabled

• Descriptive Flexfield:

  • Cost Accrual Identifier: COST-ACCRUAL

  • Cost Basis: R

  • Cost Accrual Event Type: Cost Accrual

  • Cost WIP Event Type: Cost WIP

  c) Install the Billing Extension Package

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:

• Define an AutoAccounting rule for Cost WIP.

• Assign the Cost WIP rule and other appropriate rules to the Function Transaction of Contract for the following AutoAccounting functions:

  • Labor Cost Account

  • Expense Report Cost Account

  • Usage Cost Account

  • Burden Cost Account

  • Inventory Cost Account

  • Miscellaneous Cost Account

  • WIP Cost Account (work in process from Manufacturing)

  • Supplier Invoice Cost Account

  If you use burdened cost as cost WIP, then you must define the AutoAccounting rules for the Total Burdened Cost Debit and Credit functions and run the Distribute and Interface Total Burdened Cost processes before you generate revenue.

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:

• ITD - Cost WIP

• PTD - Cost WIP

• ITD - Cost Accrual

• PTD - Cost Accrual

• ITD - Margin

• PTD - Margin

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:

• The cost accrual calculation. For example, you may calculate cost accruals to be equal the cost WIP, instead of calculating cost accruals based on the budgets as in the cost accrual example.

• The number of accounts to which you charge cost WIP or cost accruals. The cost accrual example uses one account for each bucket: Cost Accrual, Cost Accrual Contra, and Cost WIP. If you charge your cost WIP to many accounts, you must create your own cost accrual billing extension to account for the many cost WIP accounts that you use.

• What is considered cost WIP. The cost accrual example includes all costs in cost WIP. If you need to exclude certain costs from the cost WIP calculation, you need to change your cost accrual implementation.

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.

• PA: Maintain Unbilled Receivables and Unearned Revenue Balances

• PA: Interface Unreleased Revenue to GL

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:

• Billing Extensions

• Labor Billing Extension

• Billing Cycle Extension

• Retention Billing Extension

• Automatic Invoice Approve/Release Extension

• AR Transaction Type Extension

• Output Tax Extension

• Revenue-Based Cost Accrual Extension

• Cost Accrual Billing Extension

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

• Define Payment Terms.

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:

   • Customer who is providing the funding

   • Operating unit

   • Agreement Number

   • Agreement Type

   • Currency Code

   • Amount

   • Accounts Receivable Terms

   • Revenue Hard Limit or/and Invoice Hard Limit option

   • Date this agreement expires

   • Description of the agreement

   • Administrator of the agreement

   • Organization that owns the agreement

   • Creation Date

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:

• All Labor Revenue

• Private Labor Revenue

• Public Labor Revenue

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:

• Private Professional Fee Revenue (4100)

• Public Professional Fee Revenue (4101)

Define Rules to Determine Segment Values:

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

• One rule to determine the default revenue account for private labor revenue

• One rule to determine the default revenue account for public labor revenue

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:

• All Expense Report Revenue

• Private Expense Report Revenue

• Public Expense Report Revenue

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:

• Expense Report Revenue (4300)

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.

• Name of Rule: Expense Report Revenue

• Description: Determine the expense report revenue account

• Intermediate Value Source: Constant

• Parameter Name: 4300

• Segment Value Source: Intermediate Value

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:

• Function Name: Expense Report Revenue

• Transaction Name: All Expense Report Revenue

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:

• All Usage Revenue

• Private Usage Revenue

• Public Usage Revenue

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:

• Computer Fee Revenue (4200)

• Vehicle and Equipment Revenue (4201)

• Misc. Asset Revenue (4202)

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.

• Name of Rule: Usage Revenue

• Description: Map usage items to revenue accounts using the usage expenditure type

• Intermediate Value Source: Parameter

• Parameter Name: Expenditure Type

• Segment Value Source: Segment Value Lookup Set

• Lookup Set: Usage to Revenue

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:

• Function Name: Usage Revenue Account

• Transaction Name: All Usage Revenue

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:

• All Misc Trans Revenue

• Private Misc Trans Revenue

• Public Misc Trans Revenue

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:

• All Burden Txn Revenue

• Private Burden Txn Revenue

• Public Burden Txn Revenue

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:

• All Inventory Revenue

• Private Inventory Revenue

• Public Inventory Revenue

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:

• All WIP Revenue

• Private WIP Revenue

• Public WIP Revenue

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:

• All Invoice Revenue

• Private Invoice Revenue

• Public Invoice Revenue

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:

• Subcontractor Revenue (4400)

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.

• Name of Rule: Subcontractor Revenue

• Description: Subcontractor Revenue

• Intermediate Value Source: Constant

• Constant: 4400

• Segment Value Source: Intermediate Value

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:

• Function Name: Supplier Invoice Revenue Account

• Transaction Name: All Invoice Revenue

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:

• Revenue Write-Off Events

• Revenue Write-On Events

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:

• Write-Offs (5500)

• Bonus Revenue (4500)

Define Rules to Determine Account Segment Value:

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

• One rule to supply the Write-Offs account code for the Account segment of its Accounting Flexfield

• One rule to supply the Bonus Revenue account code for the Account segment of its Accounting Flexfield

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:

• Unbilled Receivables (1101)

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.

• Name of Rule: Unbilled Receivables

• Description: Unbilled receivables asset account

• Intermediate Value Source: Constant

• Parameter Name: 1101

• Segment Value Source: Intermediate Value

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:

• Function Name: Revenue and Invoice Accounts

• Transaction Name: Unbilled Receivables Account

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:

• Accounts Receivable (1100)

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.

• Name of Rule: Accounts Receivable

• Description: Accounts receivable asset account

• Intermediate Value Source: Constant

• Parameter Name: 1100

• Segment Value Source: Intermediate Value

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:

• Function Name: Revenue and Invoice Accounts

• Transaction Name: Accounts Receivable

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:

• Unearned Revenue (2100)

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.

• Name of Rule: Unearned Revenue

• Description: Unearned revenue liability account

• Intermediate Value Source: Constant

• Parameter Name: 2100

• Segment Value Source: Intermediate Value

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:

• Function Name: Revenue and Invoice Accounts

• Transaction Name: Unearned Revenue Account

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:

• Realized Gains (4520)

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.

• Name of Rule: Realized Gains

• Description: Realized Gains income account

• Intermediate Value Source: Constant

• Parameter Name: 4520

• Segment Value Source: Intermediate Value

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:

• Function Name: Revenue and Invoice Accounts

• Transaction Name: Realized Gains Account

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:

• Realized Losses (5500)

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.

• Name of Rule: Realized Losses

• Description: Realized losses expense account

• Intermediate Value Source: Constant

• Parameter Name: 5500

• Segment Value Source: Intermediate Value

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:

• Function Name: Revenue and Invoice Accounts

• Transaction Name: Realized Losses Account

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:

• Invoice Rounding Account (2110)

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.

• Name of Rule: Invoice Rounding

• Description: Invoice rounding account

• Intermediate Value Source: Constant

• Parameter Name: 2110

• Segment Value Source: Intermediate Value

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:

• Function Name: Revenue and Invoice Accounts

• Transaction Name: Invoice Rounding Account

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:

• Stores the rounding amounts on the each line.

• Interfaces the rounding entry to Oracle Receivables along with the invoice line.

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:

• Write-Offs (5500)

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:

• Function Name: Revenue and Invoice Accounts

• Transaction Name: Invoice Write-Off Account

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

• Operating Unit Setup

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:

• Control the ability to cross charge to other operating units within a legal entity by individual receiver operating unit.

• Override the default processing method for cross charges to receiver operating units within a legal entity.

• Allow cross charges to operating units outside the legal entity.

• Use internal billing.

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:

• Internal Payables Invoice Attributes Override Extension

• Provider and Receiver Organizations Override Extension

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:

• Withholding Terms

• Withholding Terms by Expenditure Category

• Withholding Terms by Event Revenue Category

• Billing Terms

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:

• Total Withheld Amount

• Percent Complete

• Billing Cycle

• Retention Billing Client Extension

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:

• Unbilled Retention (1110)

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.

• Name of Rule: Unbilled Retention

• Description: Unbilled retention asset account

• Intermediate Value Source: Constant

• Parameter Name: 1110

• Segment Value Source: Intermediate Value

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:

• Function Name: Revenue and Invoice Accounts

• Transaction Name: Unbilled Retention Account

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:

• An invoice transaction type (Projects Invoice)

• An invoice credit memo transaction type (Projects Credit Memo)

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:

• Name: PROJECTS INVOICES

• Description: Project Accounting Invoices

• Type: Imported

• Active: Yes

• Automatic Batch Numbering: No

• Automatic Invoice Numbering: No

• Standard Transaction Type: Project Invoice

• Credit Memo Batch Source: NULL

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.

• AutoInvoice Clearing

• Freight

• Receivable

• Revenue

• Tax

• Unbilled Receivable

• Unearned Revenue

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:

• Miscellaneous Options:

  • Allow Sales Credits: Disabled

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.