If you were paying attention to the Oracle EPM Cloud world this past June, EPRCS has changed its name to “Narrative Reporting”. So why hasn’t the name of this blog series changed?

1. It’s a mental shift to change over – many folks are still getting up to speed on the new Oracle EPM Cloud terminology
2. My customers are still on legacy EPRCS licensing
3. “EPRCS” is a much shorter term than “Narrative Reporting”

I will have to think about how to manage all of this in my blog archive. In the meantime, I will still refer to the product as “EPRCS” and include both “EPRCS” and “Narrative Reporting” as tags.

Work Smarter, Not Harder

(Scott Hilburn, 2010)

So what is today’s blog post about? It’s about working smarter and not harder when it comes to Narrative Reporting formatting. Recently, I transitioned a customer’s reporting packages from Cognos Disclosure Manager (CDM) to the Narrative Reporting tool within EPRCS. (And yes, this customer is also on the legacy EPRCS licensing.) This was a migration/rebuild of a combination of CDM Word files, Excel files, and variables to Narrative Reporting Word-based report packages, so these formatting tips will be very biased towards Word-based report packages.

For those of you who have worked with the Narrative Reporting tool before, you know that formatting your report objects can lead down rabbit holes that you weren’t anticipating. Getting the embedded content, style sample, and doclet formatting just right can bring unexpected hours or days of effort. This is a normal part of the report development life cycle in general, and it can often be overlooked. Therefore, to help shortcut that process, I have a handful of formatting tips for you that are guaranteed to save you time!

Tip #1: Decide Up Front What Your Formatting Needs Are

This is where a styles guide and the report package Style Sample (more on this topic later) come into play. The first thing I do on Narrative Reporting projects is work with the customer to engineer a styles guide, which I then work off of throughout the project. Some formatting changes (like margin sizes) can have time consuming impacts down the road, so it’s important to get this right up front.

Tip #2: Different Versions of Microsoft Office Can Behave Differently

This was discovered on this project. I am running Office Excel 2013. The customer is running Office 365 ProPlus. Both versions are supported by Narrative Reporting.

No software is perfect and behaves exactly the same way across versions. In this case, the Excel “calculate sheet” behavior functions differently between the two Office versions and ended up impacting the final output of the report packages. Therefore, it’s important to understand if your organization is running multiple versions of Office and how each behaves in respect to Narrative Reporting.

Note that the particular issue encountered here has its root cause in Microsoft Office, not Oracle’s Narrative Reporting tool. But you can see the importance of the downstream impacts of Office on Smart View and Smart View-related extensions.

Tip #3: Leave 2 Blank Lines at the End of your Word Doclets

When using Word-based report packages, you’ll come to learn quickly how the final report package output is collated. When there are multiple doclets without Word “break” objects in-between, Narrative Reporting will attempt to parse them together, right after each other based on the top-to-bottom doclet order within Report Center.

If you want to ensure that the final published report package leaves a single blank line between the content from one doclet and the content from the doclet that follows, place 2 blank lines at the end of the first doclet.

2 blank lines = 1 in the final output. Here’s an example of what this looks like exactly:

Tip #4: After Authoring, Repaint the Styles

The Style Sample is a powerful feature for report packages. But only if you use it correctly.

If you haven’t heard of a Style Sample, this is the Narrative Reporting template that helps enforce consistency of formatting in report packages. It exists as a Word document with all styles, margins, etc. listed out as they expect to be used in a Word-based report package. It exists as the master slide template in PowerPoint-based report packages. You have to physically create a Style Sample and upload a version of it to the report package when you first create a new report package. The Style Sample controls important formatting objects like the margins, heading styles, header and footer text, page numbering, orientation, and more.

With a Word-based report package, you control the formatting of narrative text by defining the styles for all parts of your Word doclet: the various levels of headers, “normal” text, bulleted text, and more. However, if an Author strays from the styles defined in the Style Sample (i.e. they start bolding the “normal” style text within the doclet), Narrative Reporting assumes you want to override it. Therefore, it won’t go back and overlay that text with the “normal” style in the Style Sample. As the Author, you need to remember to go back and repaint the styles in your doclet each time before you check it in. It might sound like a lot of effort, but it can take as little as seconds, depending on how long your doclet is.

Tip #5: Understand the Main Formatting Difference Between Variables and Embedded Content

There are a lot of differences between Narrative Reporting variables and embedded content. I won’t go into detail here, but instead, focus on how they impact formatting. The biggest formatting difference will be noticeable with inline text. Embedded content inserts automatically on the next line of a doclet and left-justifies by default. Variables, however, can be put directly inline with other text with no overriding justification. This key difference will impact your design choices and help you determine when you should use which feature.

Tip #6: Understand How to Format Embedded Content

OK, so I kinda stole the thunder on this tip in the one above. The nuances of embedded content formatting are important to understand so you don’t get frustrated.

If you use a Smart View grid in an Excel reference doclet as a source for embedded content, then the first thing you need to know is that: 1) it will left-justify by default. Use variables instead if you need inline text content.

If you still want to use embedded content (or need to, in the case of grid objects), although it left-justifies by default, it is possible to center the grid. To do this you have to pad empty columns in front of the grid and include those in the named range. One bonus follow-up tip regarding this topic: figure out what the maximum pixel/width/metric is of the body of your doclet and then use that as a guide for your Excel grids. For instance, for Word doclets with a 1″ left margin and 1″ right margin, the goal pixel width was 860 for my customer. So for all embedded content, we marked at the top of the columns what the pixel size was of each column, with a sum column to ensure that it stayed within the correct measurements. The customer had already been doing this for CDM and taught the trick to me. Here’s an example of how this looks in the real world – it doesn’t have to be fancy, just functional. Note that the smaller columns also have numbers in them – you just can’t see them because they are so skinny:

If you have a skinnier grid, you can pad blank columns both before and after the grid to ensure that it is centered. As long as the blank columns are of equal widths, your embedded content will look centered within your doclet.

The second thing to know about formatting embedded content is that: 2) you can’t override any part of embedded content formatting within the doclet. You have to go back to the source reference doclet to make formatting changes.

Tip #7: Use Section Breaks to Switch the Page Orientation

Let’s say your Word-based report package is portrait orientation by default. Great! But you have that one report grid that is wider than it is tall and it would be better represented by a landscape orientation. How do you do that?

Insert a section break. You can find these further down the list in Word’s “break” options. A section break will allow you to create your own microcosm world of formatting, and you’ll be able to change the page orientation without impacting the rest of the report package. Just remember to check the override box for the orientation option (and any other option that applies) when you go to check in that doclet or else you will undo all of your hard work.

Tip #8: Font Files are Essential – Use Them!

No matter what fonts you’re using in your report package (even good old fashioned Arial or Times New Roman), you really do need to upload those font files to the Fonts folder within the EPRCS Library. You will be looking for several .ttf (true type font) files to upload.

This becomes very apparent when you attempt to preview the report package within the Web UI or download it to PDF and the result is not what you expected. Not only do you need every style of the font that you intend to use, but you’ll also need Wingding and Symbol for the bulleted font styles (shout out to Tom LeFebvre for this tip!).

One caveat: from a legal standpoint, you also need to have a license for every font that you upload. Font licenses do not come included in this product.

Tip #9: Reference Variables Deserve Their Own Formatting

Another shout out to Tom LeFebvre for this tip! If you are using data values directly within your narration, chances are good that you’re using reference variables for those, and they are being sourced from an Excel reference doclet grid. You will want to create a section within your Excel reference doclet where you list all those variables together in one place. Then reference the source grid cells here. It might seem like duplicate effort to have an Excel cell refer to the data value and then have a Narrative Reporting variable refer to that cell reference, but there are several reasons to design it this way:

1. Chasing reference variable values through grids is already hard enough. If you put your variables together in a single location, then you can more easily find which Excel cells they reference.
2. You can see what the values are in one place and what they will look like without having to trace them individually back through your grids.
3. Most importantly, you have the opportunity to reformat that data value before it’s used in your narrative text. Sometimes the source data grid uses a data format that is not useful for inline narrative text (example: red negative number formats or number of decimal places), so this gives you an opportunity to decide how you want it to look inline. In the case of my customer, the prefixed dollar symbols were stored in a separate column of Excel. So I reformatted the applicable reference variables to the Currency format so that the dollar symbol would appear directly in front of the data value, which is a much better display for narrative text.

Here’s an example of how this looks – with all sorts of yellow highlighting to indicate that this is the variables area. Again, it doesn’t have to be pretty – just functional:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Good luck out there on your Narrative Reporting projects! Formatting is always a lengthy effort with reporting in general, but it can be short cut once you have the know how!