Available options for editing calculated billing amounts

Rules for Using BR40.3 Transfer Functionality

The BR40.3 transfer functionality allows a user to transfer a transaction from one activity and/or account category to another activity and/or account category. The transfer happens by creating an offset transaction (transaction with the opposite sign as the original) to the "transfer from" activity and creating a new transaction to the "transfer to" activity. In addition to the actual transfer, this form allows changes to resource type, resource, cost amount, cost units, unit of measure and billable amount.

The following rules apply when using BR40.3 Transfer.

• The "transfer to" activity/account category combination will be required to have a status that allows transactions to post to it.

• Bill in Advance transactions are not available for transfer.

• Cost amount will always be required. If no cost amount is entered, the amount on the original "transfer from" transaction will be populated to the amount field on the "transfer to" transaction. The amount cannot be greater than the amount on the original "transfer from" transaction.

  If the amount on the original "transfer from" transaction is a debit, any amount entered must also be a debit. If the amount on the original "transfer from" transaction is a credit, any amount entered must also be a credit.

  The new amount entered will become the amount on the "transfer from" and the "transfer to" transactions. The amount on the "transfer to" transaction is always assumed to be in the transaction currency of the "transfer from" transaction.

• If there are units on the "transfer from" transaction, units will be allowed to be entered on the "transfer to" side, but are not required. If no units are entered on the "transfer to" side, the units amount on the original "transfer from" transaction will be populated to the units field on the "transfer to" transaction. If the unit on the original "transfer from" transaction is a debit, the unit entered on the "transfer to" transaction must also be a debit. If unit on original "transfer from" transaction is a credit, the unit entered on the "transfer to" transaction must also be a credit.

• It is possible that the billable amount on the "transfer to" transaction will be a different amount than the billable amount of the "transfer from" transaction. For example, this could happen if the contract currencies of the "transfer from" contract and the "transfer to" contract are different. The billable amount entered on the "transfer to" transaction isn’t necessarily the billable amount that should be reversed on the "transfer from" transaction.

  • The billable amount entered on the "transfer to" side of BR40.3 Transfer will be the billable amount for the "transfer to" transaction. It is assumed that the billable amount is entered in the contract currency of the "transfer to" activity’s contract.

  • The billable amount for the "transfer from" offset transaction is prorated based on the amount of the cost being transferred. For example, if 50% of the cost amount on the original transaction is being transferred, the billable amount on the reversing ‘transfer from’ transaction will be 50% of the billable amount of the original "transfer from" transaction.

  • The Transaction Override flag on the offset transaction of the original "transfer from" transaction will always be set to Y because the application always prorates the amount based on the cost amount being transferred, and that amount should not be overridden.

• If the Override flag on the "transfer from" transaction is set to N, the following rules apply:

  • If billable amount is left blank on the ‘transfer to’ transaction, the Override flag on the resulting ‘transfer to’ transaction will remain set to N, and the billable amount on the resulting ‘transfer to’ transaction will be calculated by AC190 using the activity/account category setup.

  • If a billable amount is entered on the ‘transfer to’ transaction, the Override flag on the resulting ‘transfer to’ transaction will be set to Y, and the billable amount entered on the BR40.3 form will become the billable amount on the resulting ‘transfer to’ transaction.

• If the Override flag on the ‘transfer from’ transaction is set to Y, the following rules apply:

  • A billable amount is required unless the activity and/or account category that the transaction is being transferred to is non-billable.

  • If a billable amount is entered on the ‘transfer to’ transaction, the Override flag on the resulting ‘transfer to’ transaction will be set to ‘Y’ and the billable amount entered on BR40.3 will become the billable amount on the resulting ‘transfer to’ transaction.

  • If a billable amount is not entered on the ‘transfer to’ transaction because the activity and/or account category it is being transferred to is non-billable, the Override flag on the resulting ‘transfer to’ transaction will be set to ‘N’ and no billable amount will be calculated for the resulting ‘transfer to’ transaction.

• The revenue amount for transactions will be populated based on the following rules:

  • If the billable amount is left blank, the revenue amount on the ‘transfer to’ transaction will be calculated by AC190 when the transaction is posted.

  • If the billable amount is entered on BR40.3 the revenue amount on the ‘transfer to’ transaction will be that billable amount entered.

  • The revenue amount on the ‘transfer from’ transaction will follow the same prorating logic as the billable amount on the ‘transfer from’ transaction. For example, if 50% of the cost amount on the original transaction is being transferred, the revenue amount on the reversing ‘transfer from’ transaction will be 50% of the revenue amount on the original ‘transfer from’ transaction.

Making Contract Level Adjustments

You can also make adjustments to contract level activities using Contract Adjustment (BR41). One reason you might need to make a contract level billing adjustment is to make currency gain or loss entries during the life of the contract. These adjustments are applied directly to account categories, and are not considered during billing and revenue recognition processes and are not reflected in ceiling and tolerances calculations.

Contract level adjustments can be either AC only or AC and GL entries.

Making Contract Level Adjustments

Reposting Adjusted Transactions

After you make any of these billing adjustments, run Activity Posting (AC190) and Accounting Unit Balance Post (AC191) or run Activity Posting (AC190) with the Post Acct Unit Balances field set to Yes. Use Invoice Calculation (BR120) in non-update mode to re-calculate your invoice amounts. When the invoice calculation is correct, run BR120 in update mode to create the invoice information. To update the invoice and create the journal entries, either use status 3 (processed) when running BR120 to release the invoice, print and interface or run Invoice Print and Interface (BR121). If you do not choose status 3 (processed) when running BR120 and run BR121 to complete the process, you can run these programs concurrently.

Adjusting Posted Transactions

If you've made an error in the billing amount on a posted transaction, you can correct the error and recalculate the billing amount using Billing and Revenue Recalculation (BR190). On BR190, you can recalculate billing amounts for transactions that have been posted by Activity Posting (AC190) but not yet billed on Invoice Calculation (BR120).

Rules for Putting Transactions on Hold

You can put transactions on hold from both the billing and the revenue recognition processes on Transaction Hold (BR42.1). You can keep transactions on hold for billing only, for revenue only, or for both billing and revenue. The hold may be a manual hold which requires it to manually be removed prior to the transaction being picked up for processing, or it may be a cyclical hold. In the case of a cyclical hold, the hold is automatically removed the next time the transaction is considered for billing and/or revenue processing. BR42 can also remove a transaction from billing and revenue processing. If this is done, the transaction will no longer be able to be maintained via BR42.

Transaction Hold displays all billable transactions that have not been run through both the billing and revenue cycles. Transactions that have been run through both the billing and revenue cycles are not eligible to be put on hold. When inquiring, if BR42 displays an N for the revenue or billing, it means that the transaction has not been billed or revenue has not been recognized. If inquire displays a Y, then billing or revenue has been run for this transaction and you will not be able to change the transaction to N or H. When inquire on the BR42 display an E for the revenue, it means that revenue exceeds the ceiling. It is also an indication that revenue has been recognized and for that reason these transactions cannot be placed on hold.

This matrix illustrates how the status flags on Transaction Hold (BR42.1) are used.

The rules for holding transactions are as follows:

• A transaction cannot be put on hold for billing if the ACTRANS billed flag is set to Y.

• A transaction cannot be put on hold for revenue if the ACTRANS revenue flag is set to Y.

• If a transaction is put on hold until it is manually released for both billing and revenue, set the cycle, and the billed and revenue flags to H. These transactions will not be released until they are changed manually. Invoice Calculation (BR120) and Revenue Calculation (BR130) will not bill or recognize revenue on these transactions.

• If a transaction is put on hold until it is manually released for billing, set the cycle and billed flags to H. This transaction is available for revenue, but will not be billed. It will not be released until manually changed. BR120 will not bill this transaction.

• If a transaction is put on hold until it is manually released for revenue, set the cycle and revenue flags to H. This transaction is available for billing, but will not be used for revenue recognition. It will not be released until manually changed. BR130 will not recognize revenue on this transaction.

• If a transaction will be put on hold for one billing cycle, set the cycle flag to Y and the billed flag to H. The billed flag will change to N after BR120 has run it through one cycle (in update mode). The next billing cycle will pick it up to bill and change the billed flag to Yes (Y).

• If a transaction will be put on hold for one revenue cycle, set the cycle flag to Y and the revenue flag to H. The revenue flag will change to N after BR130 has run it through one cycle (in update mode). The next revenue cycle will pick it up for revenue recognition and change the revenue flag to Yes (Y).

• If a transaction will be held for one revenue and one billing cycle, set the cycle flag to Y and the billed and revenue flags to H. Each flag will keep the transaction on hold for one revenue run and one billing run. The billed flag will change to Yes (Y) when BR120 is run in update mode and the revenue flag will change to Yes (Y) when BR130 is run in update mode.

• If a transaction should be removed from billing and revenue processing , set the cycle flag to N. If this is done, the transaction will no longer be able to be maintained via BR42. Additionally the override flag on the ACTRANS is set and Billing and Revenue Recalculation (BR190) cannot be used to re-establish the billing and revenue processing on that transaction.

Billing In Advance

Bill In Advance (BR46.1) allows you to create new billing transactions and add them to the invoice being processed. You might use this to add expenses that have been incurred but not yet recorded, such as airfare, to an an activity/account category on an invoice to be processed.

Bill In Advance creates two transactions for each item: an invoice detail record, and an offset transaction. The invoice detail record is included in the current invoice, but the offset transaction is not. The offset transaction is applied against the actual expense when it is billed, eliminating the possibility of double billing. The transactions created by Bill In Advance are AC only transactions and are not posted to GL.