There is no doubt that really complex reports are possible with the Financial Statement Generator (FSG) in Oracle’s Report Manager, but sometimes they take more from finance users than they give. Not only do you often wait for the IT department to create FSG reports (FSGs), but their other limitations can pilfer your productivity. Here are some reasons why FSGs are robbing you of valuable time for business analysis.
Creating, Maintaining Reports Demands Expertise
FSGs can be very complex. The reports can have multiple criteria joined together, like multiple balancing segments and cost centers. They can eliminate certain series and include certain series. FSGs also let you easily suppress zeroes for accounts with no activity so you have a more concise, readable presentation layer.
For finance users, the problem with creating complex reports is that you need in-depth knowledge of Oracle’s row and column sets, which are what Report Manager uses to build the report. The IT department must create the report, and if they are too busy with other tasks or the FSGs need extensive functionality, costly consultants may be necessary. In other words, the Oracle FSG isn’t a finance end user-driven reporting tool.
Once an FSG report is created, you’ll likely need to go back to IT if it needs updating with different information. For example, if new account numbers or segments are needed in the row or column sets that weren’t included in the original FSG report design, IT would have to go back into those sets and add them, making sure that nothing else got changed.
Ad Hoc Reporting Swindles Spontaneity
Ad hoc FSGs are created with an “Ad hoc” button in Report Manager where you can actually choose which row and column sets you want to use. Once again, though, the person creating the report has to know what the row and column sets mean, because all you get is a short description.
So it can be a trial and error process to get the ad hoc report your managers clamor for, based upon what row and column sets you think you might need. You might struggle with trying to modify an existing report or have to wait for IT to get to it. Either way, it could take days or more, not the minutes that managers expect.
Static Format Conceals Data Visibility, Accuracy
The FSGs from Report Manager can be output to a variety of presentation types, including Microsoft Excel or a PDF. While finance users can run these reports themselves, the initial Excel template for a particular report is usually set up by IT.
In addition, because of the way Oracle column and row sets export to Excel, you may have to significantly format the Excel file to make it readable and show the data you really need instead of extraneous information. Plus, it isn’t a spreadsheet format that includes more appealing Excel features like graphs, charts, and dashboards. Also, the FSG limits the report appearance, because it won’t include statistical quantities and dollar amounts on the same row.
Another issue with the data exported to Excel is that it’s static in nature, meaning you have to generate the whole report again if the Oracle numbers change. If you’re using that spreadsheet as a base for final financial reporting and linking it to other forward-facing documents, you now have inherent spreadsheet errors based on formulas that are linking the additional documents. The errors may be in the same worksheet or it may be one worksheet referencing another worksheet that you use to get to your final presentation format.
Drill Down to Details Goes Missing
When Client ADI went away with Oracle Version R12, finance users lost easy access to at least some of the transactional details behind the numbers in a report. If you now use FSGs to export static data to Excel, drill-down into subledgers and journals isn’t possible, meaning you have to spend time going back into Oracle to see them each time there is an account inquiry. This impacts both closing and ad hoc reporting processes.
FSGs Hold Closing Process Hostage
Monthly, quarterly, and year-end closing processes are often stressful times for Oracle accounting and finance users, especially when using FSGs. It can take days to run a reporting package and reconcile accounts, because if errors are found in the exported spreadsheet (or other format), you have to go back and correct the entries in Oracle and run the reports again—and maybe again and again.
One reason monthly closing takes so long is the lack of available drill-down functionality mentioned earlier. If, for example, a revenue number in your P&L spreadsheet looks small, you can’t easily drill down to see which journal entries weren’t posted and where they need adjustment. Once you have found them, you still have to run the FSGs again to see if the report is correct.
Stopping the Spree: Putting FSGs Behind Bars
If you’re frustrated by stolen time due to FSG functionality, you may wonder what reporting alternatives exist. As noted, Client ADI has gone away, and likewise, so has support for Oracle Business Intelligence Discover. Oracle Business Intelligence Enterprise Edition (OBIEE) is the option Oracle pushes, but it’s a time consuming, costly implementation with a steep learning curve.
For some finance users, an option for realizing more time to analyze data is an Excel add-in that makes Excel “ERP aware.” With it, you can actually create those complex financial packages and ad hoc reports inside Excel without knowledge of Oracle row and column sets. And you can automatically pull data into a spreadsheet containing dashboards and other attractive features without limitations imposed by FSGs.
Excel add-in reports link to real-time live Oracle data so they aren’t static, and refresh with a mouse click whenever Oracle data updates, allowing you to escape those time-stealing FSG runs and resulting errors. Because of this, account reconciliations and month end closes only rob you of minutes, not days. By trying an Excel add-in, capturing and imprisoning FSGs can be a liberating and productive experience.
Ready to learn more? Contact us to discover how insightsoftware helps companies optimize Oracle reporting.