Previous	Next		Contents	Index	Navigation	Glossary	Library

There are also specific questions of client extension design that are unique to determining the requirements and logic of your billing extensions. We list these questions in the pages that follow, and then address some of these issues in further detail in the Concepts of Billing Extension Definitions section.

Understanding Billing Extensions Classes

Class 1: Based on a function of the revenue and invoice amounts included on draft revenue and invoices

An example is a Surcharge billing extension, which is typically a percentage of the invoice amount. This is the simplest class of billing extension to design and write.

Class 2: Based on values independent of the amounts included on draft revenue and invoices.

An example is the percent complete revenue accrual method, which is based on the physical percent complete entered for the project multiplied by the budget revenue amount. The calculated amount is independent of other amounts included on the revenue and invoice. In many cases, this class of billing extensions may be the only method used to calculate revenue and invoice amounts for the project, particularly if you are using Event based revenue accrual and invoicing.

Class 3: Based on the attributes of a group of transactions included on draft invoices, for which the billing extension calculates the amount to bill for these transactions.

For example, you may wish to calculate the revenue and invoice amounts based on number of days worked, rather than the actual hours worked which are recorded on the timecard. Another example is volume discounts on an invoice, in which you provide discounts based on the volume of transactions billed. You calculate the amount to bill for the group of transactions without specifying a bill amount for each transaction.

To properly track which individual transactions are billed using an automatic event, you must set up your projects to include these transactions on an invoice, but without an invoice amount. These transactions must have a nonzero revenue amount and a invoice amount of zero. Oracle Projects includes these transactions on the invoice on a net zero adjustment line which you cannot review in the forms, but that you can read from the database in your billing extension. You can set up a project to process transactions in this way by using different revenue and invoice burden schedules; the revenue schedule determines the appropriate revenue amounts and the invoice schedule calculates a invoice amount equal to zero.

Oracle Projects links the detail transactions to the invoice on a net zero adjustment invoice line, and you hold and account for the summary bill amount for these transactions using an automatic event included on the invoice. You can then write custom reports to list the detail transactions that backup the summary event amount.

You can only implement this class of billing extensions for invoicing amounts. You cannot use this class for revenue amounts calculated during revenue generation.

Designing Billing Extensions

You should consider the additional design issues for billing extensions:

• Are you calculating a revenue amount, an invoice amount, or both? Are the amounts generated during revenue accrual, invoice generation, or both?

• How are the amounts calculated? What are the inputs to the calculation?

• How are the inputs derived?

• How are the amounts processed: (1) for reporting purposes (2) for accounting purposes, (3) for invoicing?

• How are the attributes of the automatic event set: event type, event organization, event description, completion date?

• Under what conditions is this calculation used? What types of projects? What types of billing terms?

• How is the billing extension processed for adjustments? Adjustments are defined as revenue credits or invoice credit memos, based on other transactions.

• Can this billing extension be called with other billing extensions on the same project/task? If so, what is the dependency and order of your billing extensions?

• What is the exception handling if some input values cannot be found?

• How is the logic affected if the inputs change over time?

• Is there a limit on the amount calculated? If so, what is the logic?

• Are there implications of the level at which the project is funded - either the project level or the top task level? If so, what are they?