Solve the Net Bookings Puzzle
Oracle E-Business Suite's Order Management module is an incredibly flexible and functional solution for meeting 90% of the order processing needs of most companies. Unfortunately, its design focuses primarily on transacting orders, not reporting on orders. Thus, if your operations or finance department needs net bookings or historical backlog to make strategic decisions, then they'll require something beyond vanilla E-Business Suite.
Two primary areas are not addressed by the Order Management module’s vanilla functionality. First, transaction audit detail is not provided. If a change is made to an order or order line, the system simply overwrites the old value with the new value. When you run a bookings report for an order after having changed a line’s price from $10 to $20, there is no visibility to the fact that the line had once had been priced at $10. This lack of change history makes it impossible to generate accurate historical bookings figures.
For example, when trying to calculate net bookings for a designated period, the totals on a bookings report that is run on February 1st for the month of January may not reconcile to the totals of the same report run for the same period the very next day. This is because Oracle Order Management allows users to update the value of booked lines without recording the net value change and the date the change occurred. Therefore, a $2,000 order booked on January 31st, could suddenly become a $5,000 order during February, yet still maintain its January 31st booked date. Most companies would like to see the system reflect a $2,000 booking for January and a net change booking of an additional $3,000 for February.
Second, Order Management does not provide a mechanism to easily access meaningful and comprehensive summary and detail order information from bookings to revenue recognition with fully integrated user interfaces or reports. Many reports are provided by the Order Management module, however they are typically insufficient to answer key business questions, are provided in formats that provide too much or too little infomration or do not allow the user to select, sort and/or filter data as needed. Questions like the following are often impossible or extremely time consuming to answer:
For these reasons, companies spend months and hundreds of thousands of dollars developing, maintaining and/or implementing custom solutions, data warehouses and/or OLAP tools focused exclusively on the area we like to call BBB or Bookings, Backlog and Billings.
To provide companies with immediate functionality to fill these gaps, reduce IT expenses and alleviate month end headaches for financial analysts we have developed BBB Intelligence for Oracle E-Business Suite (EBS). BBB Intelligence may be broken down into two components: The Booking Transaction History Module and the BBB Views.
Booking Transaction History Module:
Understanding the BTH Engine
Account Set Processing
In order to accurately track valuation changes to booked orders, the BTH engine utilizes mechanism that should be familiar to accountants and financial analysts called “account set processing”. Essentially, the BTH engine transforms your Order Management module into a sub ledger by creating double entry journals of debits and credits every time a change is made to a booked order that affects its value with respect to date and sales credit. Thus, the change in order value becomes the amount of the debit or credit and the sales order line and salesperson are the "account" into which booking value is assigned. See the example below.
Axis verses Value Columns
Another concept that is important to understand when using the BTH engine is Axis or "Account" verses Value columns. Based on your requirements for tracking and reporting changes to bookings, the BTH engine can be configured specifically to meet your needs. To fully understand how to custom configure the BTH engine, and how changes to the configuration will impact your data and reports, you must understand the roles these two column types play and how to set them up.
An Axis or Account column is one that is tracked to group or bucket net bookings. For example, salesperson and order line are pre-configured in the BTH engine to function as the Axis columns. This means that the BTH engine will store transaction data in the BTH table so that a net booking figure can be derived for any date, salesperson, order line or combination of thereof. Any non-order value impacting column that is within, or has a foreign key reference to, the orders, lines or sales credits tables may be set up as an Axis column. To initialize a new axis column you must do the following:
1. Register the column’s table in the Configure BTH Audit Trigger page, if not already registered.
2. Set the Trigger Based attribute to “Y”
A Value column is one that directly affects the sales order value of an order when changed. These columns have already been pre-configured in the BTH engine to trigger the creation of an account set transaction whenever they are modified. They are ordered quantity, cancelled quantity, selling price, currency code and currency conversion rate.
By default, the BTH engine tracks all transactions which affect the value of an order, order line or sales credit and records the date and time the transaction took place. If you book an order on the 31st for $5,000, and the following day change the sales person for the associated sales credit on the order, the BTH will reflect the original $5,000 booking on the 31st. It will then show a negative booking of $5,000 on the 1st followed by a new booking of $5,000 on the 1st for the new sales person. Thus the net bookings for the first sales person on the 31st is $5,000 and -$5,000 on the 1st, which net to $0. The new sales person will be allocated with a $5,000 booking on the 1st. Oracle Order Management will not and can not do this!
“*” (Denotes the state of the line as originally booked.)
Note: This incorrectly reflects a $5,000 booking credited to Mary on 31-Jan.
Because BTH transactions are processed in real time, reports can be run at any time, consistently giving accurate results when run over any period. In addition, because the information is stored in your e-Business Suite database just like any other table that is used by Oracle E-Business Suite, it is readily available for use with custom reports, ad hoc queries, data warehouse interfaces, query tools, etc… Results become consistent, accurate and timely.