[Published in the Spring 2002 OAUG Forum]
The Trouble with Bookings
Oracle Order Management (Order Entry pre-11i) was designed to capture and transact orders. It's creators did an excellent job in making those transactions flexible and configurable so that they could meet almost any company's ordering needs. However, configurability translates into complexity and confusion when trying to report on order and revenue data. This presentation will discuss the inherent difficulties with reporting and developing reports for OM and how to address them to deliver accurate and meaningful information to users.
There are several factors to consider when addressing the topic of bookings in OE/OM. Since bookings are generally reported to determine projected revenue, you need to consider that not every transaction in OE/OM is destined to generate revenue. Sales order types such as Internal or Demo are entered, booked and shipped in OE/OM, but do not pass on to AR because they are not designed to generate revenue or receivables, they merely facilitate the shipment of product. The Order Cycle (Workflow in R11i) assigned to these order types excludes the Receivables Interface step, and thus prevents the order from passing to AR. When developing booking reports, you may want an option that identifies and/or filters orders that do not pass on to AR. But, you also want to be careful not to use hard coded logic that may require programming changes when your Oracles configurations are modified.
Along that same line, certain order types may be assigned to AR transactions types that have alternate uses other than accounting for revenue. For instance, AR transaction types have two key attributes that affect revenue accounting:
The Receivables Flag (Accounting Affect Flag)
- Enables/Disables the creation of Receivables for customer transactions assigned this transaction type.
The Post to GL Flag
- Enables/Disables posting to the GL for customer transactions assigned this transaction type.
Thus, transaction types may be defined and assigned to order types to drive specialized functionality, which make it prudent to be able to identify and/or filter these types of orders from your revenue projections.
Additionally, item attributes must be considered since they affect the line item’s eligibility for such processes as shipment, invoice, revenue recognition, etc. You don’t want reports designed to reflect invoiceable bookings to include line items that don’t invoice, and conversely, you don’t need to include non-shippable line items on reports designed to reflect physical customer shipments. Since the configurations and rules that govern the flow of sales order line items is complex in Oracle, reporting in this area is often a frustrating and never ending process between end user and programmer.
When determining bookings for a period, you must also consider how discounts, quantity changes, cancellations and returns affect total bookings and the period in which you want to account for these changes to bookings. If your company tracks bookings by month, then your method of determining this value should recognize that an order booked in January may be changed in February, thus affecting the net bookings for that order in January, possibly after January Bookings reports have already run. Thus, you are in danger of overstating January bookings and understating February bookings! For example, let’s say we booked an order for $500 in January and changed it in February.
Note that the Booked Date in OE/OM does not change. Even though $300 of value was added to the order in February, OE/OM indicates that this $800 order was booked on 30-JAN-00. This will result in month over month booking totals that do not reconcile.
Finally, whenever considering bookings, the calculation of sales commissions is always an issue. If you can’t accurately account for bookings and booking changes with respect to sales persons, how can you determine, for those companies who base commissions on bookings, the accurate basis for calculating commissions? Therefore, you must have a good understanding of how Sales Credits are assigned in OE/OM and how changes to those assignments, or “splits”, affect the bookings valuation for the sales persons involved. Using the example from above, let’s review a sample sales credit split.
Here you can see that in January, Bob was assigned 100% of $500 of bookings. But in February, an adjustment was made to reflect Sue’s participation on the sale. She was allocated 50% of the sales credit. Thus, the value of Bob’s sales credit is now only $250.
This becomes troublesome for the analyst responsible for calculating commissions for the following reason: There is no historical account of changes made to the sales credits.
In January, Bob had $500 in bookings credit. A split occurs in February, which reduces Bob’s bookings for January to $250 and increases Sue’s bookings in January to $250. That’s right, January! Even though the split occurred in February. No record remains of Bob’s original $500 credit. Bob’s original $500 commission may have already been paid by this time. There is no automated mechanism to inform the analyst that a change has occurred in February, nor will this change appear in any February booking reports, since OE/OM doesn’t record this as a change to the order line or modify the booked date of the order to reflect a change in credit allocation in February. It will, however, maintain the date that the sales credit was inserted or last updated, which is something to keep in mind when designing your custom reports.
Many who read this brief article might be saying to themselves: “These are exactly the problems we’ve been facing.” And, “We’ve spent months customizing Oracle to fix just these issues, but can’t quite get it right. What can we do?” Or, “How can Oracle ship software that doesn’t handle this?” Well, the fact is, Oracle does. But the good news is, there is a cost effective solution: BBB Intelligence.
BBB Intelligence is a turnkey solution, automating the Sales Order and Revenue Reporting process from business transaction through data transformation to data presentation all within your existing Oracle environment. Not only does it provide accurate and timely sales order change history, it comes equipped with over 25 business meaningful and ready to use reports and views targeting Bookings, Backlog, Billings and cost information. It requires no additional programming, setup or maintenance. Best of all, BBB Intelligence can be up and running in just 5 days - providing an immediate return on your investment!
With BBB Intelligence, you can simplify your reporting process, saving you time and money; and empower your decision makers, assuring your company's survival and success.
Visit www.absolute-tech.com for more information.
Cameron Larner
Absolute Technologies, Inc.
cam@absolute-tech.com
|
