![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
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.
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.
You should consider the additional design issues for billing extensions:
Previous | Next | Contents | Index | Navigation | Glossary | Library |