If you create an event with both revenue and bill amounts, the revenue amount and the bill amount do not have to be the same. You can create positive or negative event amounts with billing extensions.

You can create a billing extension that is called by both revenue generation and invoice generation. You would do this if your billing calculation is similar for both the revenue and bill amounts, with the exception that the event revenue amount is based on the accrued revenue, and the event bill amount is based on the amount invoiced. You can write your procedure to have the same logic for the calculation but to use the appropriate input of either accrued revenue or amount invoiced into your calculation. With this approach of writing one procedure and one billing extension, you can avoid duplication of your logic. In addition, your project users only need to assign one billing extension to their projects, instead of two billing extensions - one for revenue accrual and one for invoicing.

Calling Place

There are several predefined places within the revenue generation and invoice generation programs where your billing extension can be called when processing a project:

Pre-Processing

Delete Processing

Cancel Invoice Processing

Write-Off Invoice Processing

Adjustment Processing

Regular Processing

Post-Regular Processing

Post-Processing

The following figures illustrate the order in which these steps are executed after the project is selected for revenue accrual or invoice generation.

Figure 1 - 66.

When Revenue Processes Call Billing Extensions

Figure 1 - 67.

When Invoice Processes Call Billing Extensions

Pre-Processing

Pre-processing billing extensions are called before any revenue accrual or invoice calculations for a project. The Generate Draft Revenue and Generate Draft Invoices processes do not allow you to create automatic events in this calling place. An example of a preprocessing billing extension is to place all unbilled, unpaid supplier invoice items on hold, so that they are not billed; and to release the billing hold on any unbilled, paid supplier invoice transactions that are on hold. You can then bill the paid supplier invoice items during standard invoice processing.

Delete Processing

Delete processing billing extensions are called after revenue is billed and before any revenue accrual or invoice calculations for a project; this is only applicable to invoicing billing extensions The Generate Draft Invoices process does not allow you to create automatic events in this calling place.

Cancel Invoice Processing

Cancel invoice processing billing extensions are called after the invoice cancellation for a project. This is only applicable to invoice billing extensions. The Generate Draft Invoices process does not allow you to create automatic events in this calling place.

Write-Off Invoice Processing

Write-off invoice processing billing extensions are called after the invoice write-off processing for a project. This is only applicable to invoice billing extensions. The Generate Draft Invoices process does not allow you to create automatic events in this calling place.

Adjustment

Adjustment processing creates crediting revenue and invoices that credit existing revenue or invoices. Oracle Projects creates crediting revenues and invoices due to changes in revenue or invoice amounts or in the revenue general ledger account. These credits are created for one or more individual transactions which have previously been processed and included on a draft revenue or invoice; these changes in amounts or accounts result from adjustment actions on the individual transactions.

You can create automatic events in this step. If you transfer these events to Oracle Receivables for autoinvoicing, link the automatic event invoice lines to their corresponding events in the original invoice. See: Inserting Events. Oracle Projects calls a billing extension in this step after all of the crediting revenue and invoices are created.

Regular

Regular processing creates non-crediting revenue and invoices. Oracle Projects creates revenue and invoices based on individual transactions and events that have not previously been processed for revenue accrual and invoicing.

You can create automatic events in this step. Oracle Projects calls a billing extension in this step after all non-crediting revenues and invoices are created.

Post-Regular

Post-regular processing billing extensions create events based on all prior revenue generated in order to base the calculation on the total revenue accrued, including other automatic events. An example of a post-regular processing billing extension is cost accrual based on the revenue generated. See: Revenue-Based Cost Accrual.

Post-Processing

Post-processing billing extensions are called after all of the adjustment, regular, and post-regular processing is complete. The Generate Draft Revenue and Generate Draft Invoices processes do not allow you to create automatic events in this calling place. All of the revenue and invoice processing is complete before this step is executed. An example of a post-processing billing extension is to notify a project manager when an invoice greater than $25,000 is created.

The following table shows an example of the different automatic events created by using different calling places for a billing extension based on a percentage of the amount invoiced.

The billing extension called only during regular processing accounted for the total amount invoiced, including the credited amount during regular processing as illustrated by the event created for invoice number three.

Transaction Independent

Once you determine the inputs to your calculations, you can determine if your billing extension calculation is solely dependent on other transactions being processed, or if your calculation can be executed without any other transactions being processed. Transactions refer to expenditure items and events.

Transaction independentbilling extensions are executed for each project with an active billing assignment, even if there are no transactions to process. This type of billing extension relies on an input other than billable transactions on a project. If this input changes, the calculated billing amount changes, which you want to record. For example, the cost-to-cost revenue accrual method, which relies on the budgeted cost and revenue amounts. If the budgeted cost or budgeted revenue changes, the revenue amount changes. You want to record this revenue amount change even if no other transactions are processed in revenue generation. This category includes the class of billing extensions that calculate revenue and invoice amounts based on values independent of the amounts included on draft revenue and invoices.

Note: If you design a billing extension to be transaction independent, it will be executed in every run of the revenue or invoice processes.

Transaction dependent billing extensions are executed only if there are other transactions processed. An example of this type of billing extension is surcharge in which you calculate a percentage of the amount billed. You do not want to bill surcharge if no other transactions are billed.

Transaction dependent billing extensions are called only if billable expenditure items and events exist that need to be processed. For example, there may be new transactions that are set to Non-Billable, which are not going to generate any revenue or bill amount and will not cause the billing extension to be called. This category includes billing extensions that calculate revenue and invoice amounts based on (i) a function of the revenue and invoice amounts included on draft revenue and invoices, or (ii) the attributes of a group of transactions included on draft invoices.

The following table shows an example of transaction dependent and transaction independent billing extensions. Billing extension 1, which is transaction dependent, calculates 10% of the invoice amount. Billing extension 2, which is transaction independent, bills $100 per period regardless of amount invoiced in that period.

Relationship between Calling Place and Transaction Independent

The parameters for calling place and transaction independent are related.

You should call any transaction dependent billing extension in both regular and adjustment processing. This will ensure that all adjustments, including those that do not result in a new non-crediting amount, are properly accounted for. For example, you may have a non-billable adjustment which reverses amounts, but does not process any new non-crediting amounts.

You only need to call your transaction independent billing extension once during processing for a project, which can be done during regular processing. You typically do not call transaction independent billing extensions during adjustment processing.

The table below summarizes how you should set up the calling place and transaction independent parameters in your billing extension definition, based on the type of billing extension calculation.

There are exceptions to the general rule described in Table 1 - 114. You may define a billing extension as transaction dependent, but to be called only during regular processing. For example, you want to charge interest on outstanding invoices, but only want to include the interest on an invoice that has other transactions included on it. The interest calculation itself is a transaction independent calculation, but you define it as transaction dependent so that it is calculated only when other transactions are processed for an invoice. You do not want to create invoices with only an interest amount.

Project-Specific

You need to determine if your billing extension implements a company policy across projects or if it is applicable only to specific projects for which it is negotiated.

Project-specific billing extensions are those methods which are applicable only to specific projects for which they are negotiated. Project users assign these billing extensions to projects and top tasks; you cannot assign these billing extensions to project types.

Non-project-specific billing extensions are those methods which implement company policy across projects. You assign these billing extensions to project types; the billing extension applies to all projects of that project type. Project users cannot assign these billing extensions to projects.

Suggestion: You can include conditional logic in your procedure to allow exceptions to project type rules.

Event Attributes

When designing billing extensions, you can specify the attributes of automatic events that are created by billing extensions. You can use the following default values or override the defaults for any of these attributes.

Event Attribute

Comments

Event Type

Defaults to event type on billing extension; event type must have an event type classification of Automatic.

Event Description

Defaults to event description on billing extension.

Event Organization

Defaults to managing organization of project or task to which the event is assigned.

Completion Date

Accrue through date for events created during revenue generation, bill through date for events created during invoice generation.

Revenue Amount

For billing extensions called in revenue generation, must specify revenue amount.
For billing extensions called in invoice generation, can optionally specify revenue amount; revenue amount is not processed until invoice on which the event is billed is released.

Bill Amount

For billing extensions called in invoice generation, must specify bill amount.
For billing extensions called in revenue generation, can optionally specify bill amount; bill amount is not processed until revenue for the event is accrued.

Descriptive Flexfield Segments

Can pass any value as long as the value is valid with the descriptive flexfields you have defined for events.

Audit Columns in Events

For values used in billing extension calculations. NOTE: not displayed to the user, but available in the table. See: Insert events.

Budget Attributes

When designing billing extensions, you can specify the attributes of budgets that are used by billing extensions. You can use the following default values or override the defaults for any of these attributes.